#33854 [Bgs]: array_diff depending on element sequence
ID: 33854 User updated by: bob dot siefkes at packardbell dot com Reported By: bob dot siefkes at packardbell dot com Status: Bogus Bug Type: Arrays related Operating System: XP SP2 PHP Version: 5.0.4 New Comment: I'm aware of the assoc variant. Still I'm not convinced that array_diff behaves regular. The manual describes: array_diff() returns an array containing all the values of array1 that are not present in any of the other arguments. The value c exist in array1 and in array2. The result does also contain value c. I would not expect to see c in the result. Previous Comments: [2005-07-25 22:32:44] [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 if you want keys position to be considered use the array_diff_assoc() function. [2005-07-25 21:26:16] bob dot siefkes at packardbell dot com I did confuse the two result blocks... Expected result: -- Actual result: [2005-07-25 21:23:22] bob dot siefkes at packardbell dot com Description: Behavor of array_diff is dependent on the sequence of the elements in the array. See $array2 where I changed the sequence of a=c with a=d and it results in different output. Be noted that the key of both elements is the same, still I would not expect array_diff to take this into account. Bob Reproduce code: --- // source 1 $array1 = array(a = c, b = b ); $array2 = array(a = c, a = d ); $result = array_diff($array1, $array2); // source 2 $array1 = array(a = c, b = b ); $array2 = array(a = d, a = c ); $result = array_diff($array1, $array2); Expected result: // result1: Array ( [a] = c [b] = b ) // result2 Array ( [b] = b ) Actual result: -- // for both I would expect Array ( [b] = b ) -- Edit this bug report at http://bugs.php.net/?id=33854edit=1
#33862 [NEW]: Cookie doesnot work
From: phoenixheart at gmail dot com Operating system: RedHat Linux PHP version: 4.4.0 PHP Bug Type: Session related Bug description: Cookie doesnot work Description: setcookie() doesnot function on several machines if 3rd parameter is presented; Reproduce code: --- setcookie(myCookie,myValue,time() + 3600); Expected result: A cookie named myCookie should be created. Actual result: -- No cookie with name myCookie was created. If 3rd param (time() + 3600 or other variable) was presented, then th eabove snip of code does work well. -- Edit bug report at http://bugs.php.net/?id=33862edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33862r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33862r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33862r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33862r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33862r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33862r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33862r=needscript Try newer version: http://bugs.php.net/fix.php?id=33862r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33862r=support Expected behavior: http://bugs.php.net/fix.php?id=33862r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33862r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33862r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33862r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33862r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33862r=dst IIS Stability: http://bugs.php.net/fix.php?id=33862r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33862r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33862r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33862r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33862r=mysqlcfg
#33489 [Fbk-Opn]: Certain true type fonts shows squares instead of text
ID: 33489 User updated by: informatica at diputacionavila dot es Reported By: informatica at diputacionavila dot es -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux Fedora Core 2 PHP Version: 5.1.0b2 Assigned To: pajoye New Comment: Here you have links to some problematic fonts http://www.diputacionavila.es/weather.ttf http://www.diputacionavila.es/vacation.ttf http://www.diputacionavila.es/wingdng3.ttf http://www.diputacionavila.es/zaf.ttf If you need anything else... Previous Comments: [2005-07-23 18:47:18] [EMAIL PROTECTED] Please provide a link to the ttf fonts causing problems. I may try to allow broken fonts. But only if the changes will not break well defined fonts. --Pierre [2005-06-28 09:08:25] [EMAIL PROTECTED] Pierre, you broke this? :) [2005-06-28 08:26:30] informatica at diputacionavila dot es Freetype libs are the same in both systems. I have also tryed other versions of freetype. I'm talking about php 5.0.3 and beyond, so I've tested it in 5.0.3, 5.0.4 and 5.1.0b2 whith the same result. If I get back to 5.0.2 it works fine. [2005-06-27 14:29:25] [EMAIL PROTECTED] ..and the underlying freetype libs, etc. are the same in both systems? And you're reporting this bug to be in 5.1b2, even as you only talk about 5.0.2 / 3..so REALLY try the b2 before reporting something.. [2005-06-27 13:47:21] informatica at diputacionavila dot es Description: Certain true type fonts shows squares instead of text. Common fonts works fine (Times, Arial...) and some symbol fonts too. But weather.tff don't. You can download the font from www.diputacionavila.es/weather.ttf Reproduce code: --- ?php Header(Content-type: image/png); $gif = ImageCreate(200,200); $bg = ImageColorAllocate($gif,22,222,2); $ellipse = ImageColorAllocate($gif,2,200,200); $tx = ImageColorAllocate($gif,255,255,128); ImageFilledRectangle($gif,0,0,200,200,$bg); $black = imagecolorallocate($gif, 0,0,0); ImageTtfText ($gif, 20, 0, 0, 90, $black, /weather.ttf,123ABCabc...); ImagePNG($gif); ? Expected result: This is what I see in php5.0.2 http://www.diputacionavila.es/xgarbage/gif3.php Actual result: -- This is what I see in php5.0.3 and beyond http://rh.homelinux.net/xgarbage/gif3.php -- Edit this bug report at http://bugs.php.net/?id=33489edit=1
#33859 [Opn-Bgs]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
Previous Comments:
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33862 [Opn-Bgs]: Cookie doesnot work
ID: 33862 Updated by: [EMAIL PROTECTED] Reported By: phoenixheart at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: RedHat Linux PHP Version: 4.4.0 New Comment: 99% likely that the times on the server and the machines you tested this on were out of synch. Relying on users to have their clocks set accurately for short-timeout cookies like this is a bad idea. Use a session-cookie or a longer-range cookie and embed the actual timeout based on your server's time into the cookie value itself. Previous Comments: [2005-07-26 09:05:41] phoenixheart at gmail dot com Description: setcookie() doesnot function on several machines if 3rd parameter is presented; Reproduce code: --- setcookie(myCookie,myValue,time() + 3600); Expected result: A cookie named myCookie should be created. Actual result: -- No cookie with name myCookie was created. If 3rd param (time() + 3600 or other variable) was presented, then th eabove snip of code does work well. -- Edit this bug report at http://bugs.php.net/?id=33862edit=1
#33861 [Opn-Fbk]: error date(G) time function
ID: 33861 Updated by: [EMAIL PROTECTED] Reported By: yesman78 at hanmail dot net -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: linux 2.6.12 PHP Version: 5CVS-2005-07-26 (dev) New Comment: Can't reproduce. Please provide more info. Previous Comments: [2005-07-26 05:45:39] yesman78 at hanmail dot net Description: error time function DATE(G) Reproduce code: --- error time function DATE(G) now time : 2005.7.26 12 echo date(YnjG); run page : 20057263 3 time error Expected result: time function error Actual result: -- time function error -- Edit this bug report at http://bugs.php.net/?id=33861edit=1
#33857 [Opn-Fbk]: token_get_all() inconsistent results?
ID: 33857 Updated by: [EMAIL PROTECTED] Reported By: sr at brightlight dot ch -Status: Open +Status: Feedback -Bug Type: Unknown/Other Function +Bug Type: Scripting Engine problem Operating System: Mac OS X 10.4.1 PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-07-26 00:04:18] sr at brightlight dot ch Description: Obviously the same problem as in Bug #33093, which is set to bogus (no comment). When I tokenize the very same code over and over again I happen to get different tokens. About 9 times out of 10 I get: Token'', Token '?', Token T_STRING 'php', Token T_WHITESPACE '\n', About 1 time out of 10 Times I get Token T_OPEN_TAG '?php\n', So the first case happens far more often. By saying the same code btw. I mean that I put the tokenizing function into a for-loop. So the code doesn't even get touched. PHP 5.0.4 (entropy.ch's binary), Apache 2.0.54, Mac OS X 10.4.1 PPC. The tokenized files encoding (I tried UTF-8 no BOM and ISO- Latin-1) doesn't seem to play a role. Line endings are always Unix-style. -- Edit this bug report at http://bugs.php.net/?id=33857edit=1
#33858 [Opn-Bgs]: PHP executed in SSI doesn't show output
ID: 33858 Updated by: [EMAIL PROTECTED] Reported By: slimandslam at gmail dot com -Status: Open +Status: Bogus Bug Type: CGI related Operating System: FreeBSD 5.4 Stable PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-07-26 01:27:34] slimandslam at gmail dot com Description: When running PHP 5.04 as a CGI under Apache 2, PHP files included in Server-Side includes don't show their output. Note that the PHP files in SSI *are* executed, but the output is never shown. Running PHP 5.04 as an Apache module works as expected -- the output of the PHP files in a SSI is displayed. Reproduce code: --- To reproduce, make sure you are running PHP 5.04 as a CGI. Setup your Apache 2 web server to work with Server-Side Includes using the file extension .shtml. The file we'll run is called junk.shtml : html body !--#include virtual=./junk.php -- /body /html In the same directory as junk.shtml, put the file junk.php: ?php echo FUN FUN FUN; ? Expected result: FUN FUN FUN Actual result: -- [BLANK PAGE] -- Edit this bug report at http://bugs.php.net/?id=33858edit=1
#33863 [NEW]: the object PDOObj Row must be detroyed after use
From: lmelloul at free dot fr
Operating system: win32
PHP version: 5.1.0b3
PHP Bug Type: PDO related
Bug description: the object PDOObj Row must be detroyed after use
Description:
Error Apache.
The PDO object row is not reinitialize.
I need to write $PDOobj = null after use.
Not necessary with other fetch mode.
I Use extension=php_pdo_oci.dll
Reproduce code:
---
$st = $db-prepare(SELECT * FROM NIVEAU4);
$st-execute();
while($PDOobj = $st-fetch(PDO_FETCH_LAZY)) {
echo $PDOobj-CODNIV4 - $PDOobj-LIBNIV4 br /;
$PDOobj = null; // this statement repare the bug
}
Expected result:
Liste of code
Actual result:
--
Ok when I write $PDOobj = null
othewise Apache.exe - Application error
l'instuction à 0x00769c7a emploie l'adresse mémore 0x0017. la
mémoire ne peut être read.
--
Edit bug report at http://bugs.php.net/?id=33863edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33863r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33863r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33863r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33863r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33863r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33863r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33863r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33863r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33863r=support
Expected behavior: http://bugs.php.net/fix.php?id=33863r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33863r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33863r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33863r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33863r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33863r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33863r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33863r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33863r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33863r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33863r=mysqlcfg
#33863 [Opn-Fbk]: the object PDOObj Row must be detroyed after use
ID: 33863
Updated by: [EMAIL PROTECTED]
Reported By: lmelloul at free dot fr
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: win32
PHP Version: 5.1.0b3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-07-26 11:20:10] lmelloul at free dot fr
Description:
Error Apache.
The PDO object row is not reinitialize.
I need to write $PDOobj = null after use.
Not necessary with other fetch mode.
I Use extension=php_pdo_oci.dll
Reproduce code:
---
$st = $db-prepare(SELECT * FROM NIVEAU4);
$st-execute();
while($PDOobj = $st-fetch(PDO_FETCH_LAZY)) {
echo $PDOobj-CODNIV4 - $PDOobj-LIBNIV4 br /;
$PDOobj = null; // this statement repare the bug
}
Expected result:
Liste of code
Actual result:
--
Ok when I write $PDOobj = null
othewise Apache.exe - Application error
l'instuction à 0x00769c7a emploie l'adresse mémore 0x0017. la
mémoire ne peut être read.
--
Edit this bug report at http://bugs.php.net/?id=33863edit=1
#33680 [Bgs-Csd]: maximum number of 170 php_admin_values can be in one apache configuration
ID: 33680 User updated by: mail at tabor dot info Reported By: mail at tabor dot info -Status: Bogus +Status: Closed Bug Type: Apache2 related Operating System: FreeBSD 5.3 PHP Version: 4.3.11 New Comment: So, it seems to me that it was some problem in php-4.3.11. After upgrade on php-4.4.0 this problem disapeared. Anyway, I didn't try to reproduce this error on another system. Previous Comments: [2005-07-13 19:43:04] mail at tabor dot info Yeah! You're maybe right. Now I have collected quite a lot of data and proofs and it seems that Apache should be a part which makes these problems. But why I'm not completely decided about it is a fact that it makes just only php oriented things. php_value is not working too. It looks like 170 parameters for php module is a limit. So this looks like libphp4 thing. What do you mean now? [2005-07-13 17:49:19] [EMAIL PROTECTED] So why did you decide that it's a PHP problem and not Apache one? Report it to Apache developers. [2005-07-13 17:02:07] me at tabor dot info Yes, It was the first thing which I checked. There is nothing. Just a message about stopping apache. That's why I decided to report a bug. Yes, I set LogLevel to the value debug. [2005-07-13 16:48:01] [EMAIL PROTECTED] What do you mean doesn't start ? Open the error_log and figure out why it doesn't. [2005-07-13 16:44:15] mail at tabor dot info Description: I have normal PHP and APACHE2 configuration. I use php_admin_values to set up some virtual servers specifically. Now I have 170 parameters where php_admin_value is used. When I add just one .i.e., php_admin_value display_errors On into the virtual server configuration, Apache will not start. Is it normal? I didn't found in the documentation any mention about this. -- Edit this bug report at http://bugs.php.net/?id=33680edit=1
#33864 [NEW]: Odbc connection
From: lmelloul at free dot fr Operating system: win32 PHP version: 5.1.0b3 PHP Bug Type: PDO related Bug description: Odbc connection Description: Problem to execute query on progress database USING php_pdo_odbc.dll I am connected successfull. but when I execute a query - I have apache error. it works with standard odbc functions. I Use Progress OpenEdge V10 environnement with Data direct 4.2 32 Bit -- Edit bug report at http://bugs.php.net/?id=33864edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33864r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33864r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33864r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33864r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33864r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33864r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33864r=needscript Try newer version: http://bugs.php.net/fix.php?id=33864r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33864r=support Expected behavior: http://bugs.php.net/fix.php?id=33864r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33864r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33864r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33864r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33864r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33864r=dst IIS Stability: http://bugs.php.net/fix.php?id=33864r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33864r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33864r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33864r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33864r=mysqlcfg
#33864 [Opn-Fbk]: Odbc connection
ID: 33864 Updated by: [EMAIL PROTECTED] Reported By: lmelloul at free dot fr -Status: Open +Status: Feedback Bug Type: PDO related Operating System: win32 PHP Version: 5.1.0b3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip If you still expirience this problem, please add more info about it. A short but complete reproduce script would be really helpful. Previous Comments: [2005-07-26 11:37:03] lmelloul at free dot fr Description: Problem to execute query on progress database USING php_pdo_odbc.dll I am connected successfull. but when I execute a query - I have apache error. it works with standard odbc functions. I Use Progress OpenEdge V10 environnement with Data direct 4.2 32 Bit -- Edit this bug report at http://bugs.php.net/?id=33864edit=1
#33854 [Bgs]: array_diff depending on element sequence
ID: 33854 Updated by: [EMAIL PROTECTED] Reported By: bob dot siefkes at packardbell dot com Status: Bogus Bug Type: Arrays related Operating System: XP SP2 PHP Version: 5.0.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Your $array2 isn't valid -- you can't have two array elements with the same key. From your given results, it looks like PHP is only keeping the second a- element in each case. Previous Comments: [2005-07-26 08:38:29] bob dot siefkes at packardbell dot com I'm aware of the assoc variant. Still I'm not convinced that array_diff behaves regular. The manual describes: array_diff() returns an array containing all the values of array1 that are not present in any of the other arguments. The value c exist in array1 and in array2. The result does also contain value c. I would not expect to see c in the result. [2005-07-25 22:32:44] [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 if you want keys position to be considered use the array_diff_assoc() function. [2005-07-25 21:26:16] bob dot siefkes at packardbell dot com I did confuse the two result blocks... Expected result: -- Actual result: [2005-07-25 21:23:22] bob dot siefkes at packardbell dot com Description: Behavor of array_diff is dependent on the sequence of the elements in the array. See $array2 where I changed the sequence of a=c with a=d and it results in different output. Be noted that the key of both elements is the same, still I would not expect array_diff to take this into account. Bob Reproduce code: --- // source 1 $array1 = array(a = c, b = b ); $array2 = array(a = c, a = d ); $result = array_diff($array1, $array2); // source 2 $array1 = array(a = c, b = b ); $array2 = array(a = d, a = c ); $result = array_diff($array1, $array2); Expected result: // result1: Array ( [a] = c [b] = b ) // result2 Array ( [b] = b ) Actual result: -- // for both I would expect Array ( [b] = b ) -- Edit this bug report at http://bugs.php.net/?id=33854edit=1
#33863 [Fbk-Opn]: the object PDOObj Row must be detroyed after use
ID: 33863
User updated by: lmelloul at free dot fr
Reported By: lmelloul at free dot fr
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: win32
PHP Version: 5.1.0b3
New Comment:
OK the last php 5.1 DEV solve the bug
Previous Comments:
[2005-07-26 11:26:21] [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
[2005-07-26 11:20:10] lmelloul at free dot fr
Description:
Error Apache.
The PDO object row is not reinitialize.
I need to write $PDOobj = null after use.
Not necessary with other fetch mode.
I Use extension=php_pdo_oci.dll
Reproduce code:
---
$st = $db-prepare(SELECT * FROM NIVEAU4);
$st-execute();
while($PDOobj = $st-fetch(PDO_FETCH_LAZY)) {
echo $PDOobj-CODNIV4 - $PDOobj-LIBNIV4 br /;
$PDOobj = null; // this statement repare the bug
}
Expected result:
Liste of code
Actual result:
--
Ok when I write $PDOobj = null
othewise Apache.exe - Application error
l'instuction à 0x00769c7a emploie l'adresse mémore 0x0017. la
mémoire ne peut être read.
--
Edit this bug report at http://bugs.php.net/?id=33863edit=1
#33863 [Opn-Csd]: the object PDOObj Row must be detroyed after use
ID: 33863
Updated by: [EMAIL PROTECTED]
Reported By: lmelloul at free dot fr
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: win32
PHP Version: 5.1.0b3
New Comment:
Ok, marking as closed then.
Previous Comments:
[2005-07-26 13:32:35] lmelloul at free dot fr
OK the last php 5.1 DEV solve the bug
[2005-07-26 11:26:21] [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
[2005-07-26 11:20:10] lmelloul at free dot fr
Description:
Error Apache.
The PDO object row is not reinitialize.
I need to write $PDOobj = null after use.
Not necessary with other fetch mode.
I Use extension=php_pdo_oci.dll
Reproduce code:
---
$st = $db-prepare(SELECT * FROM NIVEAU4);
$st-execute();
while($PDOobj = $st-fetch(PDO_FETCH_LAZY)) {
echo $PDOobj-CODNIV4 - $PDOobj-LIBNIV4 br /;
$PDOobj = null; // this statement repare the bug
}
Expected result:
Liste of code
Actual result:
--
Ok when I write $PDOobj = null
othewise Apache.exe - Application error
l'instuction à 0x00769c7a emploie l'adresse mémore 0x0017. la
mémoire ne peut être read.
--
Edit this bug report at http://bugs.php.net/?id=33863edit=1
#33865 [NEW]: local_retval_ptr should be initialized to NULL
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 5CVS-2005-07-26 (dev)
PHP Bug Type: Scripting Engine problem
Bug description: local_retval_ptr should be initialized to NULL
Description:
In zend_execute_API.c zend_call_user_function() the local_retval_ptr
variable should be initialized to NULL; otherwise it could lead to a
memory read access failure.
Expected result:
Index: zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.328
diff -u -r1.328 zend_execute_API.c
--- zend_execute_API.c 21 Jul 2005 16:52:32 - 1.328
+++ zend_execute_API.c 26 Jul 2005 11:42:27 -
@@ -531,7 +531,7 @@
zval ***params_array;
zend_uint i;
int ex_retval;
- zval *local_retval_ptr;
+ zval *local_retval_ptr = NULL;
if (param_count) {
params_array = (zval ***) emalloc(sizeof(zval **)*param_count);
--
Edit bug report at http://bugs.php.net/?id=33865edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33865r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33865r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33865r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33865r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33865r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33865r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33865r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33865r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33865r=support
Expected behavior: http://bugs.php.net/fix.php?id=33865r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33865r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33865r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33865r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33865r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33865r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33865r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33865r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33865r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33865r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33865r=mysqlcfg
#33866 [NEW]: OCIlogon do not returns conn resource for account with expired paswd
From: moreauv at ppg dot com Operating system: Windows 2000 PHP version: 4.4.0 PHP Bug Type: OCI8 related Bug description: OCIlogon do not returns conn resource for account with expired paswd Description: Hi, PHP OCIlogon do not returns a valid connection resource for account with expired password. ocierror() contain: [code] = 28001 [message] = ORA-28001: the password has expired Oracle OCI return code OCI_SUCCESS_WITH_INFO is returned when issuing a OCIlogon with an expired password, and a valid connection ressource is returned by Oracle. A connection resource is needed to call OCIpasswordchange. Thanks for your help, Vincent -- Edit bug report at http://bugs.php.net/?id=33866edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33866r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33866r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33866r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33866r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33866r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33866r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33866r=needscript Try newer version: http://bugs.php.net/fix.php?id=33866r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33866r=support Expected behavior: http://bugs.php.net/fix.php?id=33866r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33866r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33866r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33866r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33866r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33866r=dst IIS Stability: http://bugs.php.net/fix.php?id=33866r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33866r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33866r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33866r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33866r=mysqlcfg
#33866 [Opn-Sus]: OCIlogon do not returns conn resource for account with expired paswd
ID: 33866 Updated by: [EMAIL PROTECTED] Reported By: moreauv at ppg dot com -Status: Open +Status: Suspended Bug Type: OCI8 related Operating System: Windows 2000 PHP Version: 4.4.0 -Assigned To: +Assigned To: tony2001 New Comment: In any case this will not be changed in PHP4. Previous Comments: [2005-07-26 14:30:24] moreauv at ppg dot com Description: Hi, PHP OCIlogon do not returns a valid connection resource for account with expired password. ocierror() contain: [code] = 28001 [message] = ORA-28001: the password has expired Oracle OCI return code OCI_SUCCESS_WITH_INFO is returned when issuing a OCIlogon with an expired password, and a valid connection ressource is returned by Oracle. A connection resource is needed to call OCIpasswordchange. Thanks for your help, Vincent -- Edit this bug report at http://bugs.php.net/?id=33866edit=1
#33866 [Sus]: OCIlogon do not returns conn resource for account with expired paswd
ID: 33866 User updated by: moreauv at ppg dot com Reported By: moreauv at ppg dot com Status: Suspended Bug Type: OCI8 related Operating System: Windows 2000 PHP Version: 4.4.0 Assigned To: tony2001 New Comment: According to Bug #33365, it is not working in PHP 5 either Previous Comments: [2005-07-26 14:33:33] [EMAIL PROTECTED] In any case this will not be changed in PHP4. [2005-07-26 14:30:24] moreauv at ppg dot com Description: Hi, PHP OCIlogon do not returns a valid connection resource for account with expired password. ocierror() contain: [code] = 28001 [message] = ORA-28001: the password has expired Oracle OCI return code OCI_SUCCESS_WITH_INFO is returned when issuing a OCIlogon with an expired password, and a valid connection ressource is returned by Oracle. A connection resource is needed to call OCIpasswordchange. Thanks for your help, Vincent -- Edit this bug report at http://bugs.php.net/?id=33866edit=1
#33768 [Fbk-Csd]: PHP test script - run-tests.php crashes with Access Voilation Error.
ID: 33768 User updated by: mjoy_2003 at yahoo dot co dot in Reported By: mjoy_2003 at yahoo dot co dot in -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Windows Server 2003 PHP Version: 4.3.11 New Comment: This bug is found to be the same as bug 32957. Closing the bug. Previous Comments: [2005-07-19 13:01:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-07-19 12:48:48] mjoy_2003 at yahoo dot co dot in Description: Script: run-tests.php from the PHP distribution is used to test the installation. Execute this on a Windows Server 2003 and the crash is reproducible. Installation: 1. Install with the following options: --with-apxs --with-oci8 --enable-sigchild --disable-rpath Webserver : Apache 1.3.33 Reproduce code: --- 1. PHP test script - run-tests.php This file is a part of the PHP distribution in the tests/ fodler. This test has produced the same result (Access voilation error) on Windows Server 2003 and suceeds on NT and 2000. Expected result: All the tests should suceed! Actual result: -- After the first script - 001.phpt is executed and Access voilation error occurs. The trace is as follows: 'php.exe': Loaded 'C:\test\Apache\htdocs\php_tests_srg\php.exe', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 'php.exe': Loaded 'C:\test\Apache\htdocs\php_tests_srg\php4ts.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\odbc32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A\comctl32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\comdlg32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF\comctl32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\mswsock.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\dnsapi.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\winrnr.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wldap32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\rasadhlp.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\hnetcfg.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wshtcpip.dll', No symbols loaded. Unhandled exception at 0x7c83247a in php.exe: 0xC005: Access violation reading location 0x54434552. -- Edit this bug report at http://bugs.php.net/?id=33768edit=1
#33867 [NEW]: auto_prepend_file doesn't work in httpd.conf
From: t4 at wks dot ch Operating system: FreeBSD PHP version: 4.3.11 PHP Bug Type: *Directory/Filesystem functions Bug description: auto_prepend_file doesn't work in httpd.conf Description: Auto_prepend_file in .htaccess works: httpd.conf: AccessFileName .htaccess .htaccess: Php_value auto_prepend_file /absolute_path/prepend_file.php Auto_prepend_file in httpd.conf doesn't work: httpd.conf: Directory /documentroot/path/ httpd.conf: Php_value auto_prepend_file /absolute_path/prepend_file.php httpd.conf: /Directory Expected result: The expected result is that /absolute_path/prepend_file.php gets executed. Actual result: -- It does not get executed and there's nothing visibile in the errorlog. -- Edit bug report at http://bugs.php.net/?id=33867edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33867r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33867r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33867r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33867r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33867r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33867r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33867r=needscript Try newer version: http://bugs.php.net/fix.php?id=33867r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33867r=support Expected behavior: http://bugs.php.net/fix.php?id=33867r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33867r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33867r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33867r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33867r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33867r=dst IIS Stability: http://bugs.php.net/fix.php?id=33867r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33867r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33867r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33867r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33867r=mysqlcfg
#33868 [NEW]: Session cookies are set only once
From: wglynn at freedomhealthcare dot org
Operating system: Linux
PHP version: 4.3.11
PHP Bug Type: Session related
Bug description: Session cookies are set only once
Description:
After switching webservers (and upgrading PHP) over the weekend for an
internal application, our users began reporting that they were getting
logged out randomly. After triple-checking our code and web server setup,
we started digging through the PHP source, and eventually discovered the
issue.
In PHP 4.3.4 (and versions before and after 4.3.4), setting a nonzero
value of session.cookie_lifetime either via php.ini or
session_set_cookie_params() resulted in a cookie that expires a certain
number of seconds after the current page load. This has the net effect of
session.cookie_lifetime setting an inactivity timeout.
In PHP 4.3.11, session_start() sends Set-Cookie: once, with an expiration
time governed by session.cookie_lifetime. (I believe this behavior changed
for PHP 4.3.9.) So, if session.cookie_lifetime is 20 minutes, the cookie
will expire and destroy the session 20 minutes after login, regardless of
any activity.
Bug #30232 attempted to change this behavior and got a patch committed,
but it was ripped out, saying that the behavior of setting the cookie once
is intentional and correct. I feel that this behavior is completely wrong
for cases where session.cookie_lifetime is nonzero; there is no situation
where sessions should expire a fixed time after setting them, but many
situations where sessions should expire a fixed time after a call to
session_start().
My proposed fix is to always send cookies if session.cookie_lifetime is
nonzero.
Reproduce code:
---
?php
header('Refresh: 10');
session_set_cookie_params(15);
session_start();
if (!isset($_SESSION['i'])) {
$_SESSION['i'] = 1;
echo 'Started session.';
} else {
$_SESSION['i']++;
echo Page load number {$_SESSION['i']}.;
}
Expected result:
Page load number should keep incrementing for as long as the browser
keeps refreshing the page within the cookie lifetime.
Actual result:
--
The cookie expires 15 seconds after the first page load, destroying the
session.
--
Edit bug report at http://bugs.php.net/?id=33868edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33868r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33868r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33868r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33868r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33868r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33868r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33868r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33868r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33868r=support
Expected behavior: http://bugs.php.net/fix.php?id=33868r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33868r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33868r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33868r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33868r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33868r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33868r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33868r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33868r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33868r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33868r=mysqlcfg
#33868 [Opn-Asn]: Session cookies are set only once
ID: 33868
Updated by: [EMAIL PROTECTED]
Reported By: wglynn at freedomhealthcare dot org
-Status: Open
+Status: Assigned
Bug Type: Session related
Operating System: Linux
PHP Version: 4.3.11
-Assigned To:
+Assigned To: sas
Previous Comments:
[2005-07-26 17:28:48] wglynn at freedomhealthcare dot org
Description:
After switching webservers (and upgrading PHP) over the weekend for an
internal application, our users began reporting that they were getting
logged out randomly. After triple-checking our code and web server
setup, we started digging through the PHP source, and eventually
discovered the issue.
In PHP 4.3.4 (and versions before and after 4.3.4), setting a nonzero
value of session.cookie_lifetime either via php.ini or
session_set_cookie_params() resulted in a cookie that expires a certain
number of seconds after the current page load. This has the net effect
of session.cookie_lifetime setting an inactivity timeout.
In PHP 4.3.11, session_start() sends Set-Cookie: once, with an
expiration time governed by session.cookie_lifetime. (I believe this
behavior changed for PHP 4.3.9.) So, if session.cookie_lifetime is 20
minutes, the cookie will expire and destroy the session 20 minutes
after login, regardless of any activity.
Bug #30232 attempted to change this behavior and got a patch committed,
but it was ripped out, saying that the behavior of setting the cookie
once is intentional and correct. I feel that this behavior is
completely wrong for cases where session.cookie_lifetime is nonzero;
there is no situation where sessions should expire a fixed time after
setting them, but many situations where sessions should expire a fixed
time after a call to session_start().
My proposed fix is to always send cookies if session.cookie_lifetime is
nonzero.
Reproduce code:
---
?php
header('Refresh: 10');
session_set_cookie_params(15);
session_start();
if (!isset($_SESSION['i'])) {
$_SESSION['i'] = 1;
echo 'Started session.';
} else {
$_SESSION['i']++;
echo Page load number {$_SESSION['i']}.;
}
Expected result:
Page load number should keep incrementing for as long as the browser
keeps refreshing the page within the cookie lifetime.
Actual result:
--
The cookie expires 15 seconds after the first page load, destroying the
session.
--
Edit this bug report at http://bugs.php.net/?id=33868edit=1
#33869 [NEW]: Strtotime no longer parses +1day or +1year etc...
From: jeremy at techtrav dot com
Operating system: Windows XP Apache 2
PHP version: 5.1.0b3
PHP Bug Type: Date/time related
Bug description: Strtotime no longer parses +1day or +1year etc...
Description:
the newest snap of php 5.1.X does not parse strtotime properly for adding
days. This used to work in 5.0.4. Look at the reproduceable code below.
The new version only seems to work with a space between the number and the
days or months or years.
Reproduce code:
---
$date = strtotime('20 Aug');
echo date('m/d/Y H:m:s', strtotime('+5days',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1month',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1year',$date));
Expected result:
08/25/2005 00:08:00
09/20/2005 00:09:00
08/20/2006 00:08:00
Actual result:
--
01/01/1970 00:01:00
01/01/1970 00:01:00
01/01/1970 00:01:00
--
Edit bug report at http://bugs.php.net/?id=33869edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33869r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33869r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33869r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33869r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33869r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33869r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33869r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33869r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33869r=support
Expected behavior: http://bugs.php.net/fix.php?id=33869r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33869r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33869r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33869r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33869r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33869r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33869r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33869r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33869r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33869r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33869r=mysqlcfg
#33870 [NEW]: relative include from symbolic linked file
From: jtaal at eljakm dot nl
Operating system: linux
PHP version: 4.3.11
PHP Bug Type: Unknown/Other Function
Bug description: relative include from symbolic linked file
Description:
On my development server I have a directory:
/var/www/app
containing the file:
menu.inc
dbsettings.inc
and the symbolic links
db_mysql.inc - /var/export/db_mysql.inc
subdir - /var/export/subdir
In the directory /var/export:
db_mysql.inc
In the directory /var/export/subdir:
include.inc
The file db_mysql.inc has the following line:
require_once(dbsettings.inc);
The file include.inc has the following line:
require_once(../menu.inc);
What happens is that the include_path is ., so the file ../menu.inc
cannot be found by include.inc
I tried to set the include_path to /var/www/app. This worked for the file
db_mysql.inc, but it didn't work for menu.inc. I tried to set the include
path to .:/var/www/app, but then the file dbsettings.inc couldn't be
found.
I also tried /var/www/app:/var/www/app/subdir and lots of other
combinations.
On a release server the two directories are merged so there will be no
symlinks. (The problem I have does not occur on this server)
I googled lots of hours, but didn't find any thing useful.
I expected PHP to open the symlinked files as if they were actually
there.
Can I configure PHP to do so?
Reproduce code:
---
/var/export/db_mysql.inc:
require_once('dbsettings.inc');
/var/export/subdir/include.inc:
require_once('../menu.inc');
/var/www/app/menu.inc:
$menu = array( ... );
/var/www/app/dbsettings.inc:
$host = 'localhost';
$user = '...';
...
symlinks:
/var/www/app/db_mysql.inc - /var/export/db_mysql.inc
/var/www/app/subdir - /var/export/subdir
Expected result:
I expected PHP to open the symlinked files as if they were actually
there.
Actual result:
--
Warning: main(../menu.inc): failed to open stream: No such file or
directory in /var/export/subdir/include.inc on line 4
Fatal error: main(): Failed opening required '../menu.inc'
(include_path='/var/www/app') in /var/export/subdir/include.inc on line 4
--
Edit bug report at http://bugs.php.net/?id=33870edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33870r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33870r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33870r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33870r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33870r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33870r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33870r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33870r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33870r=support
Expected behavior: http://bugs.php.net/fix.php?id=33870r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33870r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33870r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33870r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33870r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33870r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33870r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33870r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33870r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33870r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33870r=mysqlcfg
#33867 [Opn-Fbk]: auto_prepend_file doesn't work in httpd.conf
ID: 33867 Updated by: [EMAIL PROTECTED] Reported By: t4 at wks dot ch -Status: Open +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: FreeBSD PHP Version: 4.3.11 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Can't reproduce it with 4.4.0. Previous Comments: [2005-07-26 17:16:51] t4 at wks dot ch Description: Auto_prepend_file in .htaccess works: httpd.conf: AccessFileName .htaccess .htaccess: Php_value auto_prepend_file /absolute_path/prepend_file.php Auto_prepend_file in httpd.conf doesn't work: httpd.conf: Directory /documentroot/path/ httpd.conf: Php_value auto_prepend_file /absolute_path/prepend_file.php httpd.conf: /Directory Expected result: The expected result is that /absolute_path/prepend_file.php gets executed. Actual result: -- It does not get executed and there's nothing visibile in the errorlog. -- Edit this bug report at http://bugs.php.net/?id=33867edit=1
#33869 [Opn-Bgs]: Strtotime no longer parses +1day or +1year etc...
ID: 33869
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
Because you should write +1 day, instead of +1day.
Notice the whitespace.
Previous Comments:
[2005-07-26 17:38:32] jeremy at techtrav dot com
Description:
the newest snap of php 5.1.X does not parse strtotime properly for
adding days. This used to work in 5.0.4. Look at the reproduceable
code below. The new version only seems to work with a space between
the number and the days or months or years.
Reproduce code:
---
$date = strtotime('20 Aug');
echo date('m/d/Y H:m:s', strtotime('+5days',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1month',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1year',$date));
Expected result:
08/25/2005 00:08:00
09/20/2005 00:09:00
08/20/2006 00:08:00
Actual result:
--
01/01/1970 00:01:00
01/01/1970 00:01:00
01/01/1970 00:01:00
--
Edit this bug report at http://bugs.php.net/?id=33869edit=1
#33871 [NEW]: No Day light savings time
From: jeremy at techtrav dot com
Operating system: Windows XP Apache 2
PHP version: 5.1.0b3
PHP Bug Type: Date/time related
Bug description: No Day light savings time
Description:
the newest 5.1.X version of PHP does not seem to work with day light
savings time. the Expected result was recieved from PHP 5.0.4
I am adding 6 days to Oct 25th to cross over daylight savings time on Oct
30th. There should be 25 hours in Oct 30th.
Reproduce code:
---
$date = strtotime('25 Oct');
echo date('m/d/Y H:m:s', $date+(86400*6));
Expected result:
10/30/2005 23:10:00
Actual result:
--
10/31/2005 00:10:00
--
Edit bug report at http://bugs.php.net/?id=33871edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33871r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33871r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33871r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33871r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33871r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33871r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33871r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33871r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33871r=support
Expected behavior: http://bugs.php.net/fix.php?id=33871r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33871r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33871r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33871r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33871r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33871r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33871r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33871r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33871r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33871r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33871r=mysqlcfg
#33869 [Bgs-Opn]: Strtotime no longer parses +1day or +1year etc...
ID: 33869
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
-Status: Bogus
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
If you would read my comment you would realize this worked in php
5.0.4. I would assume you would like to keep PHP backwards compatable
with peoples code!
Previous Comments:
[2005-07-26 17:45:01] [EMAIL PROTECTED]
Because you should write +1 day, instead of +1day.
Notice the whitespace.
[2005-07-26 17:38:32] jeremy at techtrav dot com
Description:
the newest snap of php 5.1.X does not parse strtotime properly for
adding days. This used to work in 5.0.4. Look at the reproduceable
code below. The new version only seems to work with a space between
the number and the days or months or years.
Reproduce code:
---
$date = strtotime('20 Aug');
echo date('m/d/Y H:m:s', strtotime('+5days',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1month',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1year',$date));
Expected result:
08/25/2005 00:08:00
09/20/2005 00:09:00
08/20/2006 00:08:00
Actual result:
--
01/01/1970 00:01:00
01/01/1970 00:01:00
01/01/1970 00:01:00
--
Edit this bug report at http://bugs.php.net/?id=33869edit=1
#33871 [Opn-Bgs]: No Day light savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
Obviosly 6 days is not equal to 86400*6, exactly because of
daylight savings.
Change this line:
echo date('m/d/Y H:m:s', $date+(86400*6));
to
echo date('m/d/Y H:m:s', strtotime(+6 days, $date));
Previous Comments:
[2005-07-26 17:45:56] jeremy at techtrav dot com
Description:
the newest 5.1.X version of PHP does not seem to work with day light
savings time. the Expected result was recieved from PHP 5.0.4
I am adding 6 days to Oct 25th to cross over daylight savings time on
Oct 30th. There should be 25 hours in Oct 30th.
Reproduce code:
---
$date = strtotime('25 Oct');
echo date('m/d/Y H:m:s', $date+(86400*6));
Expected result:
10/30/2005 23:10:00
Actual result:
--
10/31/2005 00:10:00
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33870 [Opn-Bgs]: relative include from symbolic linked file
ID: 33870
Updated by: [EMAIL PROTECTED]
Reported By: jtaal at eljakm dot nl
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: linux
PHP Version: 4.3.11
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2005-07-26 17:39:28] jtaal at eljakm dot nl
Description:
On my development server I have a directory:
/var/www/app
containing the file:
menu.inc
dbsettings.inc
and the symbolic links
db_mysql.inc - /var/export/db_mysql.inc
subdir - /var/export/subdir
In the directory /var/export:
db_mysql.inc
In the directory /var/export/subdir:
include.inc
The file db_mysql.inc has the following line:
require_once(dbsettings.inc);
The file include.inc has the following line:
require_once(../menu.inc);
What happens is that the include_path is ., so the file ../menu.inc
cannot be found by include.inc
I tried to set the include_path to /var/www/app. This worked for the
file db_mysql.inc, but it didn't work for menu.inc. I tried to set the
include path to .:/var/www/app, but then the file dbsettings.inc
couldn't be found.
I also tried /var/www/app:/var/www/app/subdir and lots of other
combinations.
On a release server the two directories are merged so there will be no
symlinks. (The problem I have does not occur on this server)
I googled lots of hours, but didn't find any thing useful.
I expected PHP to open the symlinked files as if they were actually
there.
Can I configure PHP to do so?
Reproduce code:
---
/var/export/db_mysql.inc:
require_once('dbsettings.inc');
/var/export/subdir/include.inc:
require_once('../menu.inc');
/var/www/app/menu.inc:
$menu = array( ... );
/var/www/app/dbsettings.inc:
$host = 'localhost';
$user = '...';
...
symlinks:
/var/www/app/db_mysql.inc - /var/export/db_mysql.inc
/var/www/app/subdir - /var/export/subdir
Expected result:
I expected PHP to open the symlinked files as if they were actually
there.
Actual result:
--
Warning: main(../menu.inc): failed to open stream: No such file or
directory in /var/export/subdir/include.inc on line 4
Fatal error: main(): Failed opening required '../menu.inc'
(include_path='/var/www/app') in /var/export/subdir/include.inc on line
4
--
Edit this bug report at http://bugs.php.net/?id=33870edit=1
#33871 [Bgs-Opn]: No Day light savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
-Status: Bogus
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
Actually I realize 86400*6 should not be right as my code displays
below. It should give you back one hour short, however when I do add
86400*6 onto the day in PHP 5.1.X I am getting the exact 6 days out.
That would be a problem. Again PHP 5.0.4 handles this correctly.
Previous Comments:
[2005-07-26 17:49:24] [EMAIL PROTECTED]
Obviosly 6 days is not equal to 86400*6, exactly because of
daylight savings.
Change this line:
echo date('m/d/Y H:m:s', $date+(86400*6));
to
echo date('m/d/Y H:m:s', strtotime(+6 days, $date));
[2005-07-26 17:45:56] jeremy at techtrav dot com
Description:
the newest 5.1.X version of PHP does not seem to work with day light
savings time. the Expected result was recieved from PHP 5.0.4
I am adding 6 days to Oct 25th to cross over daylight savings time on
Oct 30th. There should be 25 hours in Oct 30th.
Reproduce code:
---
$date = strtotime('25 Oct');
echo date('m/d/Y H:m:s', $date+(86400*6));
Expected result:
10/30/2005 23:10:00
Actual result:
--
10/31/2005 00:10:00
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33871 [Opn-Fbk]: No Day light savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
Please run this code with 5.0.4 and tell me what you get:
?php
$date = strtotime('25 Oct');
var_dump(date('m/d/Y H:m:s', $date+(86400*6)));
var_dump(date('m/d/Y H:m:s', strtotime(+6 days, $date)));
?
Previous Comments:
[2005-07-26 17:53:48] jeremy at techtrav dot com
Actually I realize 86400*6 should not be right as my code displays
below. It should give you back one hour short, however when I do add
86400*6 onto the day in PHP 5.1.X I am getting the exact 6 days out.
That would be a problem. Again PHP 5.0.4 handles this correctly.
[2005-07-26 17:49:24] [EMAIL PROTECTED]
Obviosly 6 days is not equal to 86400*6, exactly because of
daylight savings.
Change this line:
echo date('m/d/Y H:m:s', $date+(86400*6));
to
echo date('m/d/Y H:m:s', strtotime(+6 days, $date));
[2005-07-26 17:45:56] jeremy at techtrav dot com
Description:
the newest 5.1.X version of PHP does not seem to work with day light
savings time. the Expected result was recieved from PHP 5.0.4
I am adding 6 days to Oct 25th to cross over daylight savings time on
Oct 30th. There should be 25 hours in Oct 30th.
Reproduce code:
---
$date = strtotime('25 Oct');
echo date('m/d/Y H:m:s', $date+(86400*6));
Expected result:
10/30/2005 23:10:00
Actual result:
--
10/31/2005 00:10:00
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33871 [Fbk-Opn]: No Day light savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
you get the expected result:
string(19) 10/30/2005 23:10:00 string(19) 10/31/2005 00:10:00
However in PHP 5.1.X I get:
string(19) 10/31/2005 00:10:00 string(19) 10/31/2005 00:10:00
Which is wrong.
Previous Comments:
[2005-07-26 17:56:24] [EMAIL PROTECTED]
Please run this code with 5.0.4 and tell me what you get:
?php
$date = strtotime('25 Oct');
var_dump(date('m/d/Y H:m:s', $date+(86400*6)));
var_dump(date('m/d/Y H:m:s', strtotime(+6 days, $date)));
?
[2005-07-26 17:53:48] jeremy at techtrav dot com
Actually I realize 86400*6 should not be right as my code displays
below. It should give you back one hour short, however when I do add
86400*6 onto the day in PHP 5.1.X I am getting the exact 6 days out.
That would be a problem. Again PHP 5.0.4 handles this correctly.
[2005-07-26 17:49:24] [EMAIL PROTECTED]
Obviosly 6 days is not equal to 86400*6, exactly because of
daylight savings.
Change this line:
echo date('m/d/Y H:m:s', $date+(86400*6));
to
echo date('m/d/Y H:m:s', strtotime(+6 days, $date));
[2005-07-26 17:45:56] jeremy at techtrav dot com
Description:
the newest 5.1.X version of PHP does not seem to work with day light
savings time. the Expected result was recieved from PHP 5.0.4
I am adding 6 days to Oct 25th to cross over daylight savings time on
Oct 30th. There should be 25 hours in Oct 30th.
Reproduce code:
---
$date = strtotime('25 Oct');
echo date('m/d/Y H:m:s', $date+(86400*6));
Expected result:
10/30/2005 23:10:00
Actual result:
--
10/31/2005 00:10:00
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33871 [Opn-Fbk]: No Day light savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
you get the expected result:
No, *I* get the expected result with both versions.
Previous Comments:
[2005-07-26 18:02:13] jeremy at techtrav dot com
you get the expected result:
string(19) 10/30/2005 23:10:00 string(19) 10/31/2005 00:10:00
However in PHP 5.1.X I get:
string(19) 10/31/2005 00:10:00 string(19) 10/31/2005 00:10:00
Which is wrong.
[2005-07-26 17:56:24] [EMAIL PROTECTED]
Please run this code with 5.0.4 and tell me what you get:
?php
$date = strtotime('25 Oct');
var_dump(date('m/d/Y H:m:s', $date+(86400*6)));
var_dump(date('m/d/Y H:m:s', strtotime(+6 days, $date)));
?
[2005-07-26 17:53:48] jeremy at techtrav dot com
Actually I realize 86400*6 should not be right as my code displays
below. It should give you back one hour short, however when I do add
86400*6 onto the day in PHP 5.1.X I am getting the exact 6 days out.
That would be a problem. Again PHP 5.0.4 handles this correctly.
[2005-07-26 17:49:24] [EMAIL PROTECTED]
Obviosly 6 days is not equal to 86400*6, exactly because of
daylight savings.
Change this line:
echo date('m/d/Y H:m:s', $date+(86400*6));
to
echo date('m/d/Y H:m:s', strtotime(+6 days, $date));
[2005-07-26 17:45:56] jeremy at techtrav dot com
Description:
the newest 5.1.X version of PHP does not seem to work with day light
savings time. the Expected result was recieved from PHP 5.0.4
I am adding 6 days to Oct 25th to cross over daylight savings time on
Oct 30th. There should be 25 hours in Oct 30th.
Reproduce code:
---
$date = strtotime('25 Oct');
echo date('m/d/Y H:m:s', $date+(86400*6));
Expected result:
10/30/2005 23:10:00
Actual result:
--
10/31/2005 00:10:00
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33871 [Fbk-Opn]: No Day light savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
I have upgraded to the newest snap as you have requested and I am still
getting the same results. PHP 5.0.4 returns the correct time. PHP
5.1.X returns the wrong time. Could this be an operating system issue?
I am on Windows XP with Apache 2.
Previous Comments:
[2005-07-26 18:05: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
you get the expected result:
No, *I* get the expected result with both versions.
[2005-07-26 18:02:13] jeremy at techtrav dot com
you get the expected result:
string(19) 10/30/2005 23:10:00 string(19) 10/31/2005 00:10:00
However in PHP 5.1.X I get:
string(19) 10/31/2005 00:10:00 string(19) 10/31/2005 00:10:00
Which is wrong.
[2005-07-26 17:56:24] [EMAIL PROTECTED]
Please run this code with 5.0.4 and tell me what you get:
?php
$date = strtotime('25 Oct');
var_dump(date('m/d/Y H:m:s', $date+(86400*6)));
var_dump(date('m/d/Y H:m:s', strtotime(+6 days, $date)));
?
[2005-07-26 17:53:48] jeremy at techtrav dot com
Actually I realize 86400*6 should not be right as my code displays
below. It should give you back one hour short, however when I do add
86400*6 onto the day in PHP 5.1.X I am getting the exact 6 days out.
That would be a problem. Again PHP 5.0.4 handles this correctly.
[2005-07-26 17:49:24] [EMAIL PROTECTED]
Obviosly 6 days is not equal to 86400*6, exactly because of
daylight savings.
Change this line:
echo date('m/d/Y H:m:s', $date+(86400*6));
to
echo date('m/d/Y H:m:s', strtotime(+6 days, $date));
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33871 [Opn-Fbk]: No Day light savings time
ID: 33871
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
This could be also a timezone issue.
What's your TZ ?
Previous Comments:
[2005-07-26 18:12:59] jeremy at techtrav dot com
I have upgraded to the newest snap as you have requested and I am still
getting the same results. PHP 5.0.4 returns the correct time. PHP
5.1.X returns the wrong time. Could this be an operating system issue?
I am on Windows XP with Apache 2.
[2005-07-26 18:05: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
you get the expected result:
No, *I* get the expected result with both versions.
[2005-07-26 18:02:13] jeremy at techtrav dot com
you get the expected result:
string(19) 10/30/2005 23:10:00 string(19) 10/31/2005 00:10:00
However in PHP 5.1.X I get:
string(19) 10/31/2005 00:10:00 string(19) 10/31/2005 00:10:00
Which is wrong.
[2005-07-26 17:56:24] [EMAIL PROTECTED]
Please run this code with 5.0.4 and tell me what you get:
?php
$date = strtotime('25 Oct');
var_dump(date('m/d/Y H:m:s', $date+(86400*6)));
var_dump(date('m/d/Y H:m:s', strtotime(+6 days, $date)));
?
[2005-07-26 17:53:48] jeremy at techtrav dot com
Actually I realize 86400*6 should not be right as my code displays
below. It should give you back one hour short, however when I do add
86400*6 onto the day in PHP 5.1.X I am getting the exact 6 days out.
That would be a problem. Again PHP 5.0.4 handles this correctly.
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33869 [Opn-Asn]: Strtotime no longer parses +1day or +1year etc...
ID: 33869
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: derick
New Comment:
Derick, is it intended change or not?
Previous Comments:
[2005-07-26 17:47:49] jeremy at techtrav dot com
If you would read my comment you would realize this worked in php
5.0.4. I would assume you would like to keep PHP backwards compatable
with peoples code!
[2005-07-26 17:45:01] [EMAIL PROTECTED]
Because you should write +1 day, instead of +1day.
Notice the whitespace.
[2005-07-26 17:38:32] jeremy at techtrav dot com
Description:
the newest snap of php 5.1.X does not parse strtotime properly for
adding days. This used to work in 5.0.4. Look at the reproduceable
code below. The new version only seems to work with a space between
the number and the days or months or years.
Reproduce code:
---
$date = strtotime('20 Aug');
echo date('m/d/Y H:m:s', strtotime('+5days',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1month',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1year',$date));
Expected result:
08/25/2005 00:08:00
09/20/2005 00:09:00
08/20/2006 00:08:00
Actual result:
--
01/01/1970 00:01:00
01/01/1970 00:01:00
01/01/1970 00:01:00
--
Edit this bug report at http://bugs.php.net/?id=33869edit=1
#33871 [Fbk-Opn]: No Day light savings time
ID: 33871
User updated by: jeremy at techtrav dot com
Reported By: jeremy at techtrav dot com
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
New Comment:
I am Central Standard Time in MN and we are on Day light Savings time.
Previous Comments:
[2005-07-26 18:16:49] [EMAIL PROTECTED]
This could be also a timezone issue.
What's your TZ ?
[2005-07-26 18:12:59] jeremy at techtrav dot com
I have upgraded to the newest snap as you have requested and I am still
getting the same results. PHP 5.0.4 returns the correct time. PHP
5.1.X returns the wrong time. Could this be an operating system issue?
I am on Windows XP with Apache 2.
[2005-07-26 18:05: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
you get the expected result:
No, *I* get the expected result with both versions.
[2005-07-26 18:02:13] jeremy at techtrav dot com
you get the expected result:
string(19) 10/30/2005 23:10:00 string(19) 10/31/2005 00:10:00
However in PHP 5.1.X I get:
string(19) 10/31/2005 00:10:00 string(19) 10/31/2005 00:10:00
Which is wrong.
[2005-07-26 17:56:24] [EMAIL PROTECTED]
Please run this code with 5.0.4 and tell me what you get:
?php
$date = strtotime('25 Oct');
var_dump(date('m/d/Y H:m:s', $date+(86400*6)));
var_dump(date('m/d/Y H:m:s', strtotime(+6 days, $date)));
?
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/33871
--
Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33865 [Opn-Csd]: local_retval_ptr should be initialized to NULL
ID: 33865
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows 2000
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
Fixed. Please don't report these kind of things as bugs,
send these to internals@ directly.
Previous Comments:
[2005-07-26 13:46:48] [EMAIL PROTECTED]
Description:
In zend_execute_API.c zend_call_user_function() the local_retval_ptr
variable should be initialized to NULL; otherwise it could lead to a
memory read access failure.
Expected result:
Index: zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.328
diff -u -r1.328 zend_execute_API.c
--- zend_execute_API.c 21 Jul 2005 16:52:32 - 1.328
+++ zend_execute_API.c 26 Jul 2005 11:42:27 -
@@ -531,7 +531,7 @@
zval ***params_array;
zend_uint i;
int ex_retval;
- zval *local_retval_ptr;
+ zval *local_retval_ptr = NULL;
if (param_count) {
params_array = (zval ***) emalloc(sizeof(zval **)*param_count);
--
Edit this bug report at http://bugs.php.net/?id=33865edit=1
#33868 [Asn-Bgs]: Session cookies are set only once
ID: 33868
Updated by: [EMAIL PROTECTED]
Reported By: wglynn at freedomhealthcare dot org
-Status: Assigned
+Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.3.11
Assigned To: sas
New Comment:
You've got confused with session maxlife and cookie max life.
There's no bug here.
Previous Comments:
[2005-07-26 17:28:48] wglynn at freedomhealthcare dot org
Description:
After switching webservers (and upgrading PHP) over the weekend for an
internal application, our users began reporting that they were getting
logged out randomly. After triple-checking our code and web server
setup, we started digging through the PHP source, and eventually
discovered the issue.
In PHP 4.3.4 (and versions before and after 4.3.4), setting a nonzero
value of session.cookie_lifetime either via php.ini or
session_set_cookie_params() resulted in a cookie that expires a certain
number of seconds after the current page load. This has the net effect
of session.cookie_lifetime setting an inactivity timeout.
In PHP 4.3.11, session_start() sends Set-Cookie: once, with an
expiration time governed by session.cookie_lifetime. (I believe this
behavior changed for PHP 4.3.9.) So, if session.cookie_lifetime is 20
minutes, the cookie will expire and destroy the session 20 minutes
after login, regardless of any activity.
Bug #30232 attempted to change this behavior and got a patch committed,
but it was ripped out, saying that the behavior of setting the cookie
once is intentional and correct. I feel that this behavior is
completely wrong for cases where session.cookie_lifetime is nonzero;
there is no situation where sessions should expire a fixed time after
setting them, but many situations where sessions should expire a fixed
time after a call to session_start().
My proposed fix is to always send cookies if session.cookie_lifetime is
nonzero.
Reproduce code:
---
?php
header('Refresh: 10');
session_set_cookie_params(15);
session_start();
if (!isset($_SESSION['i'])) {
$_SESSION['i'] = 1;
echo 'Started session.';
} else {
$_SESSION['i']++;
echo Page load number {$_SESSION['i']}.;
}
Expected result:
Page load number should keep incrementing for as long as the browser
keeps refreshing the page within the cookie lifetime.
Actual result:
--
The cookie expires 15 seconds after the first page load, destroying the
session.
--
Edit this bug report at http://bugs.php.net/?id=33868edit=1
#33868 [Bgs]: Session cookies are set only once
ID: 33868
User updated by: wglynn at freedomhealthcare dot org
Reported By: wglynn at freedomhealthcare dot org
Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.3.11
Assigned To: sas
New Comment:
I am aware that session.gc_maxlifetime can have a similar effect,
however:
1. session.cookie_lifetime gives a much finer degree of control over
the duration of the session, as different lifetimes can be assigned
based on user-specified criteria (i.e. inside hosts get one timeout,
outside hosts get another)
2. This is a deviation from earlier behavior that was not documented in
the master ChangeLog
3. This change of behavior provides no benefit for non-zero values of
session.cookie_lifetime and breaks existing software that expects
session_start() to reset the cookie expiration
4. If the new behavior is desired (for whatever reason), it can be
synthesized under the old behavior. The opposite is not true.
As I see it, the bottom line is that having session_start() send a
cookie only when the browser did not supply one reduces functionality,
breaks some existing software, and helps nothing when cookie_lifetime
is nonzero. Changing this behavior back would be trivial, and would
give a tangible benefit.
Previous Comments:
[2005-07-26 20:37:24] [EMAIL PROTECTED]
You've got confused with session maxlife and cookie max life.
There's no bug here.
[2005-07-26 17:28:48] wglynn at freedomhealthcare dot org
Description:
After switching webservers (and upgrading PHP) over the weekend for an
internal application, our users began reporting that they were getting
logged out randomly. After triple-checking our code and web server
setup, we started digging through the PHP source, and eventually
discovered the issue.
In PHP 4.3.4 (and versions before and after 4.3.4), setting a nonzero
value of session.cookie_lifetime either via php.ini or
session_set_cookie_params() resulted in a cookie that expires a certain
number of seconds after the current page load. This has the net effect
of session.cookie_lifetime setting an inactivity timeout.
In PHP 4.3.11, session_start() sends Set-Cookie: once, with an
expiration time governed by session.cookie_lifetime. (I believe this
behavior changed for PHP 4.3.9.) So, if session.cookie_lifetime is 20
minutes, the cookie will expire and destroy the session 20 minutes
after login, regardless of any activity.
Bug #30232 attempted to change this behavior and got a patch committed,
but it was ripped out, saying that the behavior of setting the cookie
once is intentional and correct. I feel that this behavior is
completely wrong for cases where session.cookie_lifetime is nonzero;
there is no situation where sessions should expire a fixed time after
setting them, but many situations where sessions should expire a fixed
time after a call to session_start().
My proposed fix is to always send cookies if session.cookie_lifetime is
nonzero.
Reproduce code:
---
?php
header('Refresh: 10');
session_set_cookie_params(15);
session_start();
if (!isset($_SESSION['i'])) {
$_SESSION['i'] = 1;
echo 'Started session.';
} else {
$_SESSION['i']++;
echo Page load number {$_SESSION['i']}.;
}
Expected result:
Page load number should keep incrementing for as long as the browser
keeps refreshing the page within the cookie lifetime.
Actual result:
--
The cookie expires 15 seconds after the first page load, destroying the
session.
--
Edit this bug report at http://bugs.php.net/?id=33868edit=1
#33871 [Opn-Asn]: No Day light savings time
ID: 33871 Updated by: [EMAIL PROTECTED] Reported By: jeremy at techtrav dot com -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Windows XP Apache 2 PHP Version: 5.1.0b3 -Assigned To: +Assigned To: derick Previous Comments: [2005-07-26 18:21:13] jeremy at techtrav dot com I am Central Standard Time in MN and we are on Day light Savings time. [2005-07-26 18:16:49] [EMAIL PROTECTED] This could be also a timezone issue. What's your TZ ? [2005-07-26 18:12:59] jeremy at techtrav dot com I have upgraded to the newest snap as you have requested and I am still getting the same results. PHP 5.0.4 returns the correct time. PHP 5.1.X returns the wrong time. Could this be an operating system issue? I am on Windows XP with Apache 2. [2005-07-26 18:05: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 you get the expected result: No, *I* get the expected result with both versions. [2005-07-26 18:02:13] jeremy at techtrav dot com you get the expected result: string(19) 10/30/2005 23:10:00 string(19) 10/31/2005 00:10:00 However in PHP 5.1.X I get: string(19) 10/31/2005 00:10:00 string(19) 10/31/2005 00:10:00 Which is wrong. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33871 -- Edit this bug report at http://bugs.php.net/?id=33871edit=1
#33872 [NEW]: readdir64() not utilized over readdir(), causes NFS failures
From: gabe at mudbugmedia dot com
Operating system: Debian Woody
PHP version: 4.3.11
PHP Bug Type: *Configuration Issues
Bug description: readdir64() not utilized over readdir(), causes NFS failures
Description:
When compiling PHP on Debian-woody, the readdir()
functionality was not overriden through configuration
definitions (such as -D_FILE_OFFSET_BITS=64) to use the 64
bit readdir function.
This leads to the failure of a program to read a directory
from an NFS share which forces 64 bit mode, such as an NFS
share from MacOSX 10.4+ and IRIX. In such cases the readdir
() function will only return two directory entities, '.' and
'..'. Examining the strace output of this process shows:
open(/tmp/files, O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2ebf8000
write(1, dir opened fine\n, 16dir opened fine
) = 16
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2168
_llseek(3, 2, [2], SEEK_SET)= 0
write(1, .\n, 2.
) = 2
write(1, ..\n, 3..
) = 3
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2120
close(3)= 0
Note that after the getdents(), _llseek() is used to rewind
it, which should not happen. In a program compiled properly
to use readdir64():
open(/tmp/files, O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x805a000) = 0x805a000
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 2168
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2579c000
write(1, .\n, 2.
) = 2
write(1, ..\n, 3..
) = 3
write(1, .DS_Store\n, 10.DS_Store
) = 10
write(1, .TemporaryItems\n, 16.TemporaryItems
) = 16
cut
write(1, Zeitzer\n, 8Zeitzer
)= 8
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 0
close(3)= 0
No _llseek() is used.
This inability for 64 bit NFS data to be read through a 32
bit readdir() is most likely due to a bug in the kernel, but
has not be addressed (this has not been confirmed, I read
this at kerneltrap but lost the link) because 32 bit readdir
() is supposed to be deprecated. Reguardless what causes
the bug, PHP should detect for this and set the appropriate
#define in it's configuration file. Several programs,
including bash, ls, and perl, all do this work around.
Reproduce code:
---
Failed sample used in the above strace:
?php
$dir = '/tmp/files';
if ($handle = opendir($dir)) {
echo dir opened fine\n;
while (false !== ($file = readdir($handle))) {
echo $file\n;
}
closedir($handle);
} else {
echo could not open dir\n;
}
?
Expected result:
Full directory content to be displayed
Actual result:
--
[EMAIL PROTECTED]:~$ php -f rd.php
dir opened fine
.
..
[EMAIL PROTECTED]:~$
--
Edit bug report at http://bugs.php.net/?id=33872edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33872r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33872r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33872r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33872r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33872r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33872r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33872r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33872r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33872r=support
Expected behavior: http://bugs.php.net/fix.php?id=33872r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33872r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33872r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33872r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33872r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33872r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33872r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33872r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33872r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33872r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33872r=mysqlcfg
#33586 [Opn-Asn]: Serialization breaks references
ID: 33586
Updated by: [EMAIL PROTECTED]
Reported By: wmeler at wp dot pl
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-07-06
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2005-07-22 08:52:12] wmeler at wp dot pl
Do you want simplest to debug example or complicated real world
example?
How about this :
?
$c = array();
$d = array();
$c['d2']=$d;
$d['c2']=$c;
$x=unserialize(serialize($c));
$x['x']='x';
$c['x']='x';
var_dump($c);
var_dump($x);
?
outputs remain the same
you can even substitute 'c' with 'parent' and 'd' with 'child' which
makes it more real but this would change outputs
[2005-07-22 01:03:09] [EMAIL PROTECTED]
In your example you're making a reference to a non-existing variable.
Please come up with something more realistic.
[2005-07-06 12:51:21] wmeler at wp dot pl
I've tried - nothing changed
[2005-07-06 12:17:00] [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
[2005-07-06 12:03:59] wmeler at wp dot pl
Description:
After serializing variable with circular reference you get 2 copies of
root variable.
Look at output of reproduce code - var_dump outputs should be the same
but they are not.
for code:
$c['d2']=$d;
$d['c2']=$c;
echo serialize($c);
you get
a:1:{s:2:d2;a:1:{s:2:c2;a:1:{s:2:d2;R:2;}}}
I think that it should be something like
a:1:{s:2:d2;a:1:{s:2:c2;R:1;}}
Reproduce code:
---
?
$c['d2']=$d;
$d['c2']=$c;
$x=unserialize(serialize($c));
$x['x']='x';
$c['x']='x';
var_dump($c);
var_dump($x);
Expected result:
array(2) {
[d2]=
array(1) {
[c2]=
array(2) {
[d2]=
array(1) {
[c2]=
array(2) {
[d2]=
*RECURSION*
[x]=
string(1) x
}
}
[x]=
string(1) x
}
}
[x]=
string(1) x
}
array(2) {
[d2]=
array(1) {
[c2]=
array(2) {
[d2]=
array(1) {
[c2]=
array(2) {
[d2]=
*RECURSION*
[x]=
string(1) x
}
}
[x]=
string(1) x
}
}
[x]=
string(1) x
}
Actual result:
--
array(2) {
[d2]=
array(1) {
[c2]=
array(2) {
[d2]=
array(1) {
[c2]=
array(2) {
[d2]=
*RECURSION*
[x]=
string(1) x
}
}
[x]=
string(1) x
}
}
[x]=
string(1) x
}
array(2) {
[d2]=
array(1) {
[c2]=
array(1) {
[d2]=
array(1) {
[c2]=
array(1) {
[d2]=
*RECURSION*
}
}
}
}
[x]=
string(1) x
}
--
Edit this bug report at http://bugs.php.net/?id=33586edit=1
#33489 [Opn-Asn]: Certain true type fonts shows squares instead of text
ID: 33489 Updated by: [EMAIL PROTECTED] Reported By: informatica at diputacionavila dot es -Status: Open +Status: Assigned Bug Type: GD related Operating System: Linux Fedora Core 2 PHP Version: 5.1.0b2 Assigned To: pajoye Previous Comments: [2005-07-26 09:18:00] informatica at diputacionavila dot es Here you have links to some problematic fonts http://www.diputacionavila.es/weather.ttf http://www.diputacionavila.es/vacation.ttf http://www.diputacionavila.es/wingdng3.ttf http://www.diputacionavila.es/zaf.ttf If you need anything else... [2005-07-23 18:47:18] [EMAIL PROTECTED] Please provide a link to the ttf fonts causing problems. I may try to allow broken fonts. But only if the changes will not break well defined fonts. --Pierre [2005-06-28 09:08:25] [EMAIL PROTECTED] Pierre, you broke this? :) [2005-06-28 08:26:30] informatica at diputacionavila dot es Freetype libs are the same in both systems. I have also tryed other versions of freetype. I'm talking about php 5.0.3 and beyond, so I've tested it in 5.0.3, 5.0.4 and 5.1.0b2 whith the same result. If I get back to 5.0.2 it works fine. [2005-06-27 14:29:25] [EMAIL PROTECTED] ..and the underlying freetype libs, etc. are the same in both systems? And you're reporting this bug to be in 5.1b2, even as you only talk about 5.0.2 / 3..so REALLY try the b2 before reporting something.. 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/33489 -- Edit this bug report at http://bugs.php.net/?id=33489edit=1
#33198 [Opn-Asn]: Leading UTF-8 byte order mark yields different character encodings in output
ID: 33198 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: * PHP Version: 5CVS-2005-06-21 -Assigned To: +Assigned To: moriyoshi Previous Comments: [2005-06-27 09:33:50] Bjorn dot Wiberg at its dot uu dot se Hi again! Sorry, but this is not connected to mod_cgi in any way. We're not using PHP through mod_cgi, but as a handler. Apache does not have a problem serving the page -- instead it seems that the error only occurs when the file is being processed by the PHP handler. Best regards, Björn [2005-06-27 00:59:30] [EMAIL PROTECTED] Check out this Apache bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=16687 [2005-06-21 17:28:22] Bjorn dot Wiberg at its dot uu dot se Hi again! I just tried the 2005-06-21 10:30 snapshot, but the problem persists. Best regards, Björn [2005-06-19 00:50:45] [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 [2005-06-16 14:44:03] Bjorn dot Wiberg at its dot uu dot se Hi! Please try the following: http://www.anst.uu.se/bwiberg/php/utf8_bug.phtml ...exhibits the bug randomly just like *.php. When in error, the output looks like this: http://www.anst.uu.se/bwiberg/php/utf8_bug_result3.txt http://www.anst.uu.se/bwiberg/php/utf8_bug.html ...does not exhibit the bug; output does not get re-encoded in any way, i.e. UTF-8 characters remain UTF-8: http://www.anst.uu.se/bwiberg/php/utf8_bug_result4.txt It appears that something happens to the output (sometimes) when PHP parses the file. Best regards, Björn 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/33198 -- Edit this bug report at http://bugs.php.net/?id=33198edit=1
#33147 [Opn-Asn]: proc_open(): pty pseudo terminal not supported on this system
ID: 33147
Updated by: [EMAIL PROTECTED]
Reported By: skissane at iips dot mq dot edu dot au
-Status: Open
+Status: Assigned
-Bug Type: Program Execution
+Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5CVS-2005-05-27
-Assigned To:
+Assigned To: sniper
Previous Comments:
[2005-07-14 08:57:44] [EMAIL PROTECTED]
I'm still waiting for someone to give me a short and reliable piece of
code (shell or C) to test if the functionality is present on the
system..
[2005-06-20 09:51:30] skissane at iips dot mq dot edu dot au
This is not really a feature/change request -- the feature is already
supported in the code; the configure system just needs to be set up so
the support can be turned on/off.
[2005-05-30 08:20:43] skissane at iips dot mq dot edu dot au
Updated test case: added SKIPIF (requires Michael Spector's
--enable-pty patch).
--TEST--
Bug #33147 (proc_open: basic test of Unix98 PTYs functionality)
--SKIPIF--
?php
ob_start();
phpinfo();
$info = ob_get_contents();
ob_end_clean();
if (strpos($info,--enable-pty) === FALSE) {
die(skip --enable-pty not specified\n);
}
?
--FILE--
?php
// Create a pseudo terminal for the child process
$descriptorspec = array(
0 = array(pty),
1 = array(pty),
2 = array(pty)
);
$process = proc_open(echo this is working, $descriptorspec, $pipes);
if (is_resource($process)) {
echo OK\n;
while (!feof($pipes[1]))
echo fread($pipes[1],1024);
}
?
--EXPECT--
OK
this is working
[2005-05-30 03:07:59] skissane at iips dot mq dot edu dot au
Wez (or someone else with CVS comitter rights): why not just check
Michael Spector's patch into CVS?
http://www.mail-archive.com/internals@lists.php.net/msg14854.html.
That should close this issue. No more of your time required :)
[2005-05-27 01:29:27] skissane at iips dot mq dot edu dot au
Tested with the patch you supplied. (Patch would not apply, so I had to
apply most of it by hand.) My test case works with the test you
supplied, and --enable-pty supplied as a config option.
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/33147
--
Edit this bug report at http://bugs.php.net/?id=33147edit=1
#33872 [Opn-Bgs]: readdir64() not utilized over readdir(), causes NFS failures
ID: 33872
Updated by: [EMAIL PROTECTED]
Reported By: gabe at mudbugmedia dot com
-Status: Open
+Status: Bogus
Bug Type: *Configuration Issues
Operating System: Debian Woody
PHP Version: 4.3.11
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #27792.
Previous Comments:
[2005-07-26 21:01:24] gabe at mudbugmedia dot com
Description:
When compiling PHP on Debian-woody, the readdir()
functionality was not overriden through configuration
definitions (such as -D_FILE_OFFSET_BITS=64) to use the 64
bit readdir function.
This leads to the failure of a program to read a directory
from an NFS share which forces 64 bit mode, such as an NFS
share from MacOSX 10.4+ and IRIX. In such cases the readdir
() function will only return two directory entities, '.' and
'..'. Examining the strace output of this process shows:
open(/tmp/files, O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2ebf8000
write(1, dir opened fine\n, 16dir opened fine
) = 16
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2168
_llseek(3, 2, [2], SEEK_SET)= 0
write(1, .\n, 2.
) = 2
write(1, ..\n, 3..
) = 3
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2120
close(3)= 0
Note that after the getdents(), _llseek() is used to rewind
it, which should not happen. In a program compiled properly
to use readdir64():
open(/tmp/files, O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x805a000) = 0x805a000
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 2168
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2579c000
write(1, .\n, 2.
) = 2
write(1, ..\n, 3..
) = 3
write(1, .DS_Store\n, 10.DS_Store
) = 10
write(1, .TemporaryItems\n, 16.TemporaryItems
) = 16
cut
write(1, Zeitzer\n, 8Zeitzer
)= 8
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 0
close(3)= 0
No _llseek() is used.
This inability for 64 bit NFS data to be read through a 32
bit readdir() is most likely due to a bug in the kernel, but
has not be addressed (this has not been confirmed, I read
this at kerneltrap but lost the link) because 32 bit readdir
() is supposed to be deprecated. Reguardless what causes
the bug, PHP should detect for this and set the appropriate
#define in it's configuration file. Several programs,
including bash, ls, and perl, all do this work around.
Reproduce code:
---
Failed sample used in the above strace:
?php
$dir = '/tmp/files';
if ($handle = opendir($dir)) {
echo dir opened fine\n;
while (false !== ($file = readdir($handle))) {
echo $file\n;
}
closedir($handle);
} else {
echo could not open dir\n;
}
?
Expected result:
Full directory content to be displayed
Actual result:
--
[EMAIL PROTECTED]:~$ php -f rd.php
dir opened fine
.
..
[EMAIL PROTECTED]:~$
--
Edit this bug report at http://bugs.php.net/?id=33872edit=1
#33873 [NEW]: parse_ini_file() bails out with parse error when NO is inside file
From: eric at aplosmedia dot com Operating system: Windows XP; RHEL 3 PHP version: 5.0.4 PHP Bug Type: Filesystem function related Bug description: parse_ini_file() bails out with parse error when NO is inside file Description: If an INI file contains a definition such as NO = 667, php will bail out with a parse error. Warning: Error parsing /home/public_html/lookup.ini on line 147 in /home/public_html/start.php on line 24 This occurs on PHP 5.0.4 on Windows XP, RHEL 3 as well as php 4.3.11 on RHEL 3 (only platforms tested) Reproduce code: --- lookup.ini ; NETHERLANDS NL = 31 ; NORWAY NO = 47 ; NEW ZEALAND NZ = 64 PHP ?php print_r( parse_ini_file( './lookup.ini' ) ); ? Expected result: should return an array: Array ( [NL] = 31 [NO] = 47 [NZ] = 64 } Actual result: -- Warning: Error parsing /home/public_html/lookup.ini on line 147 in /home/public_html/start.php on line 24 Array ( [NL] = 31 } -- Edit bug report at http://bugs.php.net/?id=33873edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33873r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33873r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33873r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33873r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33873r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33873r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33873r=needscript Try newer version: http://bugs.php.net/fix.php?id=33873r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33873r=support Expected behavior: http://bugs.php.net/fix.php?id=33873r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33873r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33873r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33873r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33873r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33873r=dst IIS Stability: http://bugs.php.net/fix.php?id=33873r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33873r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33873r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33873r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33873r=mysqlcfg
#33872 [Bgs]: readdir64() not utilized over readdir(), causes NFS failures
ID: 33872
User updated by: gabe at mudbugmedia dot com
Reported By: gabe at mudbugmedia dot com
Status: Bogus
Bug Type: *Configuration Issues
Operating System: Debian Woody
PHP Version: 4.3.11
New Comment:
Apologies, I did not originally realize that these #defines
were the same as LFS support, as the original problematic
cause affected *all* files across an NFS share, and not just
the 2+ GB ones.
Previous Comments:
[2005-07-26 21:57:50] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #27792.
[2005-07-26 21:01:24] gabe at mudbugmedia dot com
Description:
When compiling PHP on Debian-woody, the readdir()
functionality was not overriden through configuration
definitions (such as -D_FILE_OFFSET_BITS=64) to use the 64
bit readdir function.
This leads to the failure of a program to read a directory
from an NFS share which forces 64 bit mode, such as an NFS
share from MacOSX 10.4+ and IRIX. In such cases the readdir
() function will only return two directory entities, '.' and
'..'. Examining the strace output of this process shows:
open(/tmp/files, O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2ebf8000
write(1, dir opened fine\n, 16dir opened fine
) = 16
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2168
_llseek(3, 2, [2], SEEK_SET)= 0
write(1, .\n, 2.
) = 2
write(1, ..\n, 3..
) = 3
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2120
close(3)= 0
Note that after the getdents(), _llseek() is used to rewind
it, which should not happen. In a program compiled properly
to use readdir64():
open(/tmp/files, O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x805a000) = 0x805a000
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 2168
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2579c000
write(1, .\n, 2.
) = 2
write(1, ..\n, 3..
) = 3
write(1, .DS_Store\n, 10.DS_Store
) = 10
write(1, .TemporaryItems\n, 16.TemporaryItems
) = 16
cut
write(1, Zeitzer\n, 8Zeitzer
)= 8
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 0
close(3)= 0
No _llseek() is used.
This inability for 64 bit NFS data to be read through a 32
bit readdir() is most likely due to a bug in the kernel, but
has not be addressed (this has not been confirmed, I read
this at kerneltrap but lost the link) because 32 bit readdir
() is supposed to be deprecated. Reguardless what causes
the bug, PHP should detect for this and set the appropriate
#define in it's configuration file. Several programs,
including bash, ls, and perl, all do this work around.
Reproduce code:
---
Failed sample used in the above strace:
?php
$dir = '/tmp/files';
if ($handle = opendir($dir)) {
echo dir opened fine\n;
while (false !== ($file = readdir($handle))) {
echo $file\n;
}
closedir($handle);
} else {
echo could not open dir\n;
}
?
Expected result:
Full directory content to be displayed
Actual result:
--
[EMAIL PROTECTED]:~$ php -f rd.php
dir opened fine
.
..
[EMAIL PROTECTED]:~$
--
Edit this bug report at http://bugs.php.net/?id=33872edit=1
#33874 [NEW]: The Windows builds should be updated to openssl 0.9.8
From: mdlawler at gwmicro dot com Operating system: Windows XP PHP version: 5CVS-2005-07-26 (dev) PHP Bug Type: OpenSSL related Bug description: The Windows builds should be updated to openssl 0.9.8 Description: Openssl 0.9.8 hs been released and should be used in the Windows php builds -- Edit bug report at http://bugs.php.net/?id=33874edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33874r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33874r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33874r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33874r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33874r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33874r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33874r=needscript Try newer version: http://bugs.php.net/fix.php?id=33874r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33874r=support Expected behavior: http://bugs.php.net/fix.php?id=33874r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33874r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33874r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33874r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33874r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33874r=dst IIS Stability: http://bugs.php.net/fix.php?id=33874r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33874r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33874r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33874r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33874r=mysqlcfg
#33875 [NEW]: The Windows binaries should be updated to use zlib 1.23.
From: mdlawler at gwmicro dot com Operating system: Windows XP PHP version: 5CVS-2005-07-26 (dev) PHP Bug Type: Zlib Related Bug description: The Windows binaries should be updated to use zlib 1.23. Description: Zlib 1.23 has security fixes and performance improvements and the Windows binaries should be built with it rather than 1.14. Version 1.14 is embeded in php5ts.dll. -- Edit bug report at http://bugs.php.net/?id=33875edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33875r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33875r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33875r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33875r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33875r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33875r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33875r=needscript Try newer version: http://bugs.php.net/fix.php?id=33875r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33875r=support Expected behavior: http://bugs.php.net/fix.php?id=33875r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33875r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33875r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33875r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33875r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33875r=dst IIS Stability: http://bugs.php.net/fix.php?id=33875r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33875r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33875r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33875r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33875r=mysqlcfg
#33874 [Opn-Asn]: The Windows builds should be updated to openssl 0.9.8
ID: 33874 Updated by: [EMAIL PROTECTED] Reported By: mdlawler at gwmicro dot com -Status: Open +Status: Assigned Bug Type: OpenSSL related Operating System: Windows XP PHP Version: 5CVS-2005-07-26 (dev) -Assigned To: +Assigned To: edink Previous Comments: [2005-07-26 23:45:33] mdlawler at gwmicro dot com Description: Openssl 0.9.8 hs been released and should be used in the Windows php builds -- Edit this bug report at http://bugs.php.net/?id=33874edit=1
#33874 [Asn]: The Windows builds should be updated to openssl 0.9.8
ID: 33874 Updated by: [EMAIL PROTECTED] Reported By: mdlawler at gwmicro dot com Status: Assigned Bug Type: OpenSSL related Operating System: Windows XP PHP Version: 5CVS-2005-07-26 (dev) Assigned To: edink New Comment: Edin, could you plz take care of that? Previous Comments: [2005-07-26 23:45:33] mdlawler at gwmicro dot com Description: Openssl 0.9.8 hs been released and should be used in the Windows php builds -- Edit this bug report at http://bugs.php.net/?id=33874edit=1
#33875 [Opn-Asn]: The Windows binaries should be updated to use zlib 1.23.
ID: 33875 Updated by: [EMAIL PROTECTED] Reported By: mdlawler at gwmicro dot com -Status: Open +Status: Assigned Bug Type: Zlib Related Operating System: Windows XP PHP Version: 5CVS-2005-07-26 (dev) -Assigned To: +Assigned To: edink New Comment: Edin, one more for you.. Previous Comments: [2005-07-26 23:52:59] mdlawler at gwmicro dot com Description: Zlib 1.23 has security fixes and performance improvements and the Windows binaries should be built with it rather than 1.14. Version 1.14 is embeded in php5ts.dll. -- Edit this bug report at http://bugs.php.net/?id=33875edit=1
#33876 [NEW]: PDO misquotes/miscasts bool(false)
From: php at sagi dot org
Operating system: Linux
PHP version: 5CVS-2005-07-27 (dev)
PHP Bug Type: PDO related
Bug description: PDO misquotes/miscasts bool(false)
Description:
Running latest php5 snapshot (php5-200507261230), PDO connected to pgsql
8.0 server.
I'm trying to run a query similar to this:
$res = $db-prepare('SELECT id FROM table WHERE mybool = ?');
$res-execute(array(false));
PDO throws this exception: 'SQLSTATE[22P02]: Invalid text representation:
7 ERROR: invalid input syntax for type boolean: '
The query that has been executed, according to the server log, is: SELECT
id FROM table WHERE mybool = ''
Which is obviously not right. When trying to run the same query with
bool(true) parameter, PDO correctly quotes it as '1'.
--
Edit bug report at http://bugs.php.net/?id=33876edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33876r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33876r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33876r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33876r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33876r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33876r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33876r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33876r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33876r=support
Expected behavior: http://bugs.php.net/fix.php?id=33876r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33876r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33876r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33876r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33876r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33876r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33876r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33876r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33876r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33876r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33876r=mysqlcfg
#33869 [Asn-Csd]: Strtotime no longer parses +1day or +1year etc...
ID: 33869
Updated by: [EMAIL PROTECTED]
Reported By: jeremy at techtrav dot com
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: Windows XP Apache 2
PHP Version: 5.1.0b3
Assigned To: derick
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-07-26 18:17:27] [EMAIL PROTECTED]
Derick, is it intended change or not?
[2005-07-26 17:47:49] jeremy at techtrav dot com
If you would read my comment you would realize this worked in php
5.0.4. I would assume you would like to keep PHP backwards compatable
with peoples code!
[2005-07-26 17:45:01] [EMAIL PROTECTED]
Because you should write +1 day, instead of +1day.
Notice the whitespace.
[2005-07-26 17:38:32] jeremy at techtrav dot com
Description:
the newest snap of php 5.1.X does not parse strtotime properly for
adding days. This used to work in 5.0.4. Look at the reproduceable
code below. The new version only seems to work with a space between
the number and the days or months or years.
Reproduce code:
---
$date = strtotime('20 Aug');
echo date('m/d/Y H:m:s', strtotime('+5days',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1month',$date));
echo 'br';
echo date('m/d/Y H:m:s', strtotime('+1year',$date));
Expected result:
08/25/2005 00:08:00
09/20/2005 00:09:00
08/20/2006 00:08:00
Actual result:
--
01/01/1970 00:01:00
01/01/1970 00:01:00
01/01/1970 00:01:00
--
Edit this bug report at http://bugs.php.net/?id=33869edit=1
#33859 [Bgs-Opn]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
Previous Comments:
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33877 [NEW]: When multiple result sets are not freed subsequent queries fail
From: Jeffrey dot Rodriguez at gmail dot com
Operating system: Windows XP / 2000
PHP version: 5.0.4
PHP Bug Type: MSSQL related
Bug description: When multiple result sets are not freed subsequent queries
fail
Description:
NOTE:
This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4
WORKAROUND:
Be sure to call mssql_free_result() on every result that has the potential
to return multiple result sets.
PROBLEM:
When a query (stored procedure for example) returns multiple result sets,
you have to call mssql_next_result() OR mssql_free_result() on the result
of an mssql_query().
Failure to do so will cause subsequent mssql_next_query() or
mssql_select_db() calls to fail.
ADDITIONAL NOTES:
The docs should be updated if this functionality is intended.
Sorry about the 'excessive' length of code, I figure you can handle 8
extra lines.
Reproduce code:
---
?php
/* -- Stored procedure
CREATE PROCEDURE bug_proofOfConcept_sp
AS
SELECT 'Result set one' AS 'Result Set';
SELECT 'Result set two' AS 'Result Set';
GO
*/
$link = mssql_connect(server, user, pass);
mssql_select_db(database, $link);
$rs = mssql_query(EXECUTE bug_proofOfConcept_sp);
/* Note, it doesn't matter if you fetch from $rs */
/* This is where things bomb out */
if (!mssql_select_db(database, $link)) {
echo Broken, as expected.\n;
}
/* If we free the result things work fine again.
Alternatively, you could call mssql_next_result($rs) */
mssql_free_result($rs);
// Select the database (3rd, and last time)
if (!mssql_select_db(database, $link)) {
echo Everything should be working here; wtf?\n;
}
?
Expected result:
No output
Actual result:
--
Warning: mssql_select_db(): Unable to select database: database in
H:\proofOfConcept.php on line 16
Broken, as expected.
--
Edit bug report at http://bugs.php.net/?id=33877edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33877r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33877r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33877r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33877r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33877r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33877r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33877r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33877r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33877r=support
Expected behavior: http://bugs.php.net/fix.php?id=33877r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33877r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33877r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33877r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33877r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33877r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33877r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33877r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33877r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33877r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33877r=mysqlcfg
#33859 [Opn-Bgs]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
The only way to fix it would be for PHP to implement it's own SQL query
parser, pre-scan user queries and determine if any disallowed keywords
are being used. This is not only highly impractical, but would also
make database communication code very slow.
Previous Comments:
[2005-07-27 00:51:14] leon at lost dot co dot nz
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33877 [Opn]: When multiple result sets are not freed subsequent queries fail
ID: 33877
User updated by: Jeffrey dot Rodriguez at gmail dot com
Reported By: Jeffrey dot Rodriguez at gmail dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows XP / 2000
PHP Version: 5.0.4
New Comment:
Typo: Failure to do so will cause subsequent mssql_next_query() or
mssql_select_db() calls to fail.
Should read:
Failure to do so will cause subsequent mssql_query() or
mssql_select_db() calls to fail.
Previous Comments:
[2005-07-27 00:53:09] Jeffrey dot Rodriguez at gmail dot com
Description:
NOTE:
This issue seems to occur in versions (atleast) 4.3.4 - 5.0.4
WORKAROUND:
Be sure to call mssql_free_result() on every result that has the
potential to return multiple result sets.
PROBLEM:
When a query (stored procedure for example) returns multiple result
sets, you have to call mssql_next_result() OR mssql_free_result() on
the result of an mssql_query().
Failure to do so will cause subsequent mssql_next_query() or
mssql_select_db() calls to fail.
ADDITIONAL NOTES:
The docs should be updated if this functionality is intended.
Sorry about the 'excessive' length of code, I figure you can handle 8
extra lines.
Reproduce code:
---
?php
/* -- Stored procedure
CREATE PROCEDURE bug_proofOfConcept_sp
AS
SELECT 'Result set one' AS 'Result Set';
SELECT 'Result set two' AS 'Result Set';
GO
*/
$link = mssql_connect(server, user, pass);
mssql_select_db(database, $link);
$rs = mssql_query(EXECUTE bug_proofOfConcept_sp);
/* Note, it doesn't matter if you fetch from $rs */
/* This is where things bomb out */
if (!mssql_select_db(database, $link)) {
echo Broken, as expected.\n;
}
/* If we free the result things work fine again.
Alternatively, you could call mssql_next_result($rs) */
mssql_free_result($rs);
// Select the database (3rd, and last time)
if (!mssql_select_db(database, $link)) {
echo Everything should be working here; wtf?\n;
}
?
Expected result:
No output
Actual result:
--
Warning: mssql_select_db(): Unable to select database: database in
H:\proofOfConcept.php on line 16
Broken, as expected.
--
Edit this bug report at http://bugs.php.net/?id=33877edit=1
#33859 [Bgs-Opn]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
With all due respect, that's complete and utter nonsense.
However on the postitive side, at least now I can see where you were
confused.
Obviously you have assumed that the error was because my choice of
alias is also a function name (prehaps you should have ran the code to
actually test your assumption). This turns out not to be the case.
The error still occurs if I use another alias (I've also simplified
the SQL to the bare minimum for you):
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER)');
// Run problem query
$sql = SELECT count(*) AS cnt FROM barrel ORDER BY cnt;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Also, the original example SQL was perfecly valid, as demonstrated by
giving it to native sqlite3 command line program:
$ echo SELECT count(*) AS count,key FROM barrel, \
documents WHERE id == docid AND wordid == 3 \
GROUP BY docid ORDER BY count DESC; |
sqlite3 search.sqlite3
3|/main/library/index.html
2|/main/docs/page/printable.html
1|/main/apps/index.html
... and so on...
$
Previous Comments:
[2005-07-27 01:13:10] [EMAIL PROTECTED]
The only way to fix it would be for PHP to implement it's own SQL query
parser, pre-scan user queries and determine if any disallowed keywords
are being used. This is not only highly impractical, but would also
make database communication code very slow.
[2005-07-27 00:51:14] leon at lost dot co dot nz
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33879 [NEW]: $string[otherstring] = something | should produce a warning
From: sigge at hystrix dot se Operating system: PHP version: 5.0.4 PHP Bug Type: Strings related Bug description: $string[otherstring] = something | should produce a warning Description: I recently had a bug in my code that overwrote an array with a string. I missed the [], it happens. But debugging was hard, and I had a bunch of $array[foo] = bar; when $array had been overwritten by a string. As kind people on #php explained to me, PHP treats any string as 0. While I can understand such behaviour, I think there should be a warning like you are treating a string as an array or something. This warning should probably not occur when the key is a number, as this would return the character, but when accessing a string key of a string makes no sense. I can't see how this would break any backward compatibility, and it would make debugging much easier! Edit: I've now seen that there are similar bugs, all marked closed and without any non-stock explanation. I would really like to know why this is expected, because to me, having developed in PHP for two years, this wasn't expected at all, and caused me a good headache. Pardon me if I am spamming, I would prefer to add a comment to those bugs, but can't. Reproduce code: --- $array = array(); $array = string; $array[foo] = bar; Expected result: Would be nice if it produced a warning on line 3, Trying to access a string as an array -- Edit bug report at http://bugs.php.net/?id=33879edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33879r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33879r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33879r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33879r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33879r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33879r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33879r=needscript Try newer version: http://bugs.php.net/fix.php?id=33879r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33879r=support Expected behavior: http://bugs.php.net/fix.php?id=33879r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33879r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33879r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33879r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33879r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33879r=dst IIS Stability: http://bugs.php.net/fix.php?id=33879r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33879r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33879r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33879r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33879r=mysqlcfg
#33859 [Opn]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
Status: Open
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
The bottom line is that the assertion is happening inside the sqlite
library; it is therefore a libsqlite bug (because it is responsible for
that particular condition never arising).
Now, it is possible that the way that PDO uses libsqlite is leading to
that, so we can look into it more deeply.
Please also note that abusing us about our reasonable first impression
isn't going inspire anyone to come running to your aid; why don't we
keep it professional (even though we are volunteers and don't get paid
for this)?
Previous Comments:
[2005-07-27 01:33:13] leon at lost dot co dot nz
With all due respect, that's complete and utter nonsense.
However on the postitive side, at least now I can see where you were
confused.
Obviously you have assumed that the error was because my choice of
alias is also a function name (prehaps you should have ran the code to
actually test your assumption). This turns out not to be the case.
The error still occurs if I use another alias (I've also simplified
the SQL to the bare minimum for you):
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER)');
// Run problem query
$sql = SELECT count(*) AS cnt FROM barrel ORDER BY cnt;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Also, the original example SQL was perfecly valid, as demonstrated by
giving it to native sqlite3 command line program:
$ echo SELECT count(*) AS count,key FROM barrel, \
documents WHERE id == docid AND wordid == 3 \
GROUP BY docid ORDER BY count DESC; |
sqlite3 search.sqlite3
3|/main/library/index.html
2|/main/docs/page/printable.html
1|/main/apps/index.html
... and so on...
$
[2005-07-27 01:13:10] [EMAIL PROTECTED]
The only way to fix it would be for PHP to implement it's own SQL query
parser, pre-scan user queries and determine if any disallowed keywords
are being used. This is not only highly impractical, but would also
make database communication code very slow.
[2005-07-27 00:51:14] leon at lost dot co dot nz
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#32241 [Com]: Why not have mssql_insert_id function when use Microsoft sql server database!
ID: 32241 Comment by: Daniel dot Spada at det dot wa dot edu dot au Reported By: kangtk at 163 dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows2000 Server PHP Version: 4.3.10 New Comment: To expand on the previous poster. I have found that there is no such function mssql_insert_id() when using MS-SQL server. I am using PHP 4.3.10-15, with SQL server 2000. A mssql_insert_id function would be REALLY handy to assist in error checking etc. Previous Comments: [2005-03-09 03:10:31] kangtk at 163 dot com Description: I can use this function mysql_insert_id to get the insert id when I connect with mysql database. But I cann't use the mssql_insert_id when I change the code to Microsoft Sql server databse. Can you explain something to me? Thanks. -- Edit this bug report at http://bugs.php.net/?id=32241edit=1
#33859 [Opn-Bgs]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
See: http://www.sqlite.org/cvstrac/tktview?tn=1338
Previous Comments:
[2005-07-27 03:47:55] [EMAIL PROTECTED]
The bottom line is that the assertion is happening inside the sqlite
library; it is therefore a libsqlite bug (because it is responsible for
that particular condition never arising).
Now, it is possible that the way that PDO uses libsqlite is leading to
that, so we can look into it more deeply.
Please also note that abusing us about our reasonable first impression
isn't going inspire anyone to come running to your aid; why don't we
keep it professional (even though we are volunteers and don't get paid
for this)?
[2005-07-27 01:33:13] leon at lost dot co dot nz
With all due respect, that's complete and utter nonsense.
However on the postitive side, at least now I can see where you were
confused.
Obviously you have assumed that the error was because my choice of
alias is also a function name (prehaps you should have ran the code to
actually test your assumption). This turns out not to be the case.
The error still occurs if I use another alias (I've also simplified
the SQL to the bare minimum for you):
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER)');
// Run problem query
$sql = SELECT count(*) AS cnt FROM barrel ORDER BY cnt;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Also, the original example SQL was perfecly valid, as demonstrated by
giving it to native sqlite3 command line program:
$ echo SELECT count(*) AS count,key FROM barrel, \
documents WHERE id == docid AND wordid == 3 \
GROUP BY docid ORDER BY count DESC; |
sqlite3 search.sqlite3
3|/main/library/index.html
2|/main/docs/page/printable.html
1|/main/apps/index.html
... and so on...
$
[2005-07-27 01:13:10] [EMAIL PROTECTED]
The only way to fix it would be for PHP to implement it's own SQL query
parser, pre-scan user queries and determine if any disallowed keywords
are being used. This is not only highly impractical, but would also
make database communication code very slow.
[2005-07-27 00:51:14] leon at lost dot co dot nz
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
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/33859
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33533 [Csd-Opn]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 User updated by: scott dot barnett at thuringowa dot qld dot gov dot au Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Closed +Status: Open Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: Apologies for the delayed response. Trying to compile CVS, getting a missing file error. Not sure if this is related or not. checking for PDO includes... checking for PDO includes... /usr/src/apache/php5-200507270430/ext checking for selected PDO ODBC flavour... unixODBC libs /usr/local/lib, headers/usr/local/include checking for odbc.h in /usr/local/include... no checking for odbcsdk.h in /usr/local/include... no checking for iodbc.h in /usr/local/include... no checking for sqlunix.h in /usr/local/include... no checking for sqltypes.h in /usr/local/include... yes checking for sqlucode.h in /usr/local/include... yes checking for sql.h in /usr/local/include... yes checking for isql.h in /usr/local/include... yes checking for sqlext.h in /usr/local/include... yes checking for isqlext.h in /usr/local/include... yes checking for udbcext.h in /usr/local/include... no checking for sqlcli1.h in /usr/local/include... no checking for LibraryManager.h in /usr/local/include... no checking for cli0core.h in /usr/local/include... no checking for cli0ext.h in /usr/local/include... no checking for cli0cli.h in /usr/local/include... no checking for cli0defs.h in /usr/local/include... no checking for cli0env.h in /usr/local/include... no checking for SQLBindCol in -lodbc... yes checking for SQLAllocHandle in -lodbc... yes checking for PostgreSQL support for PDO... no checking for sqlite 3 driver for PDO... yes checking for PDO includes... (cached) /usr/src/apache/php5-200507270430/ext checking size of char *... 4 ./configure: line 84770: /usr/src/apache/php5-200507270430/sqlite/src/sqlite3.h: No such file or directory configure: error: this package is broken Previous Comments: [2005-07-19 17:27:19] [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. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c, __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184 #7 0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299 #8 0x00f03b8b in execute (op_array=0x89aeaec) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87 #9 0x00edd699 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200507122030/Zend/zend.c:1087 #10 0x00e9c995 in php_execute_script (primary_file=0xbfe0f4e0) at /usr/src/apache/php5-200507122030/main/main.c:1672 #11 0x00f48616 in php_handler (r=0x899fbe0) at /usr/src/apache/php5-200507122030/sapi/apache2handler/sapi_apache2.c:555 #12 0x0809953a in ap_run_handler (r=0x899fbe0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x899fbe0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x899fbe0) at http_request.c:249 #15 0x0807e225 in
#33671 [Com]: sun_rise and sun_set don't return a GMT timestamp if one passes an offset
ID: 33671 Comment by: bhazboun03 at yahoo dot com Reported By: golf at dds dot nl Status: Assigned Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.0.4 Assigned To: derick New Comment: we offer web hosting with a personal web page design - plus free web hosting and a cheap web hosting plans we are one of the best web hosting provider company www.throughhosting.com www.throughhosting.com/links ThroughSearch.com is your complete source for a fast search engine results and Search Engine Marketing tips. Our Search Engine Results are powered by Google Search Engine. www.throughsearch.com Search Engine www.throughsearch.com/directory Web directory paper Supplier - paper porducts international paper a http://www.venuspaper.com international paper arab search engine http://www.throughsearch.com/arab-search.php arab search engine Previous Comments: [2005-07-15 15:11:36] golf at dds dot nl I don't think this is the same bug as #32820. There seems to be a difference in that one doesn't get A GMT timestamp but one with an offset of +1 if one passes an offset to date_sunrise and date_sunset. This means that one seems to get a timestamp, but this isn't a timestamp. And with the other bugreport there seems to be a logic error, not a timestamp error. As before, when I use both functions I aspect to get a timestamp back for witch the timezone is GMT* and not in the timezone for witch I added the offset to the functions... *As is normal with a timestamp [2005-07-13 07:45:56] [EMAIL PROTECTED] Duplicate of: #32820 [2005-07-13 02:35:59] golf at dds dot nl I have also swaped lat and long and this solves my basic problem that the hours where wrong, but one can say that the bug is still there since my first suspision is correct, GMT offset is not used to calculate anything, it changes the timestamp to something that looks and feels like a timestamp but isn't since it isn't a GMT date/time combo but the GMT date/time combo + the offset. Since this isn't standard for timestamp I changed the status of this Bug to open... The algorithm looks to work acourding to this: http://williams.best.vwh.net/sunrise_sunset_algorithm.htm Where one can read the last line to see it is just added... My objection to the way the functions work probably won't make a change list, but it is something to add as a note to the manual becouse it is confusing (At least to me and perhaps more people). [2005-07-13 01:08:22] golf at dds dot nl After re-reading the source in the bug-report I now see that I passed $long and $lat where I should have passed $longitude, $latitude. I changed the code and now every thing seems oke... Sorry for the hassle made by this report but I realy missed this typo. Regards, Golf P.S. I tryd to add a comment to this bugreport (twice) but it didn't show up, so if there are more than one... [2005-07-13 00:53:07] golf at dds dot nl Description: With my current version of PHP5 (5.0.4-0.6.sarge.1 (Debian GNU/Linux) I run into an error if I use date_sunrise and date_sunset. This happens when I pass an GMT offset and results in a timestamp that has an offset of +1 hour to the actual sun set/rise on that date. Since timestamps are GMT/UTC and not bound to an timezone other that GMT/UTC this is wrong. I say this since I believe the GMT offset one can pass to the before mentioned functions is used in the calculation and the functions should return a timestamp like any other so it can be used by date and gmdate as those functions require a GMT/UTC timestamp... B.t.w. I use the max difference for some further calculations in my script, so there for the lage difference between astro and official sunset's/rises... Reproduce code: --- $latitude = 28 + (1/60*17) + (1/60/60*54); $longitude = (-(16 + (1/60*30) + (1/60/60*34))); $astro = 108; $official = (90 + (1/60*50)); echo Local Tenerife timebr\n; echo sunriseAstro = . gmdate(M d Y H:i:s, date_sunrise(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $astro, 1) + 60*60) . br\n; echo sunriseOffical = . gmdate(M d Y H:i:s, date_sunrise(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $official , 1) + 60*60) . br\n; echo sunsetOffical = . gmdate(M d Y H:i:s, date_sunset(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $official, 1) + 60*60) . br\n; echo sunsetAstro = . gmdate(M d Y H:i:s, date_sunset(1121208238, SUNFUNCS_RET_TIMESTAMP, $long, $lat, $astro, 1) + 60*60) . p\n; Expected result: Local Tenerife time sunriseAstro = Jul 12 2005 05:47:50 sunriseOffical = Jul 12 2005
#33671 [Com]: sun_rise and sun_set don't return a GMT timestamp if one passes an offset
ID: 33671 Comment by: bhazboun03 at yahoo dot com Reported By: golf at dds dot nl Status: Assigned Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.0.4 Assigned To: derick New Comment: we offer web hosting with a personal web page design - plus free web hosting and a cheap web hosting plans we are one of the best web hosting provider company http://www.throughhosting.com Web Hosting http://www.throughhosting.com/links directory ThroughSearch.com is your complete source for a fast search engine results and Search Engine Marketing tips. Our Search Engine Results are powered by Google Search Engine. http://www.throughsearch.com Search Engine http://www.throughsearch.com/directory directory Previous Comments: [2005-07-27 07:38:52] bhazboun03 at yahoo dot com we offer web hosting with a personal web page design - plus free web hosting and a cheap web hosting plans we are one of the best web hosting provider company www.throughhosting.com www.throughhosting.com/links ThroughSearch.com is your complete source for a fast search engine results and Search Engine Marketing tips. Our Search Engine Results are powered by Google Search Engine. www.throughsearch.com Search Engine www.throughsearch.com/directory Web directory paper Supplier - paper porducts international paper a http://www.venuspaper.com international paper arab search engine http://www.throughsearch.com/arab-search.php arab search engine [2005-07-15 15:11:36] golf at dds dot nl I don't think this is the same bug as #32820. There seems to be a difference in that one doesn't get A GMT timestamp but one with an offset of +1 if one passes an offset to date_sunrise and date_sunset. This means that one seems to get a timestamp, but this isn't a timestamp. And with the other bugreport there seems to be a logic error, not a timestamp error. As before, when I use both functions I aspect to get a timestamp back for witch the timezone is GMT* and not in the timezone for witch I added the offset to the functions... *As is normal with a timestamp [2005-07-13 07:45:56] [EMAIL PROTECTED] Duplicate of: #32820 [2005-07-13 02:35:59] golf at dds dot nl I have also swaped lat and long and this solves my basic problem that the hours where wrong, but one can say that the bug is still there since my first suspision is correct, GMT offset is not used to calculate anything, it changes the timestamp to something that looks and feels like a timestamp but isn't since it isn't a GMT date/time combo but the GMT date/time combo + the offset. Since this isn't standard for timestamp I changed the status of this Bug to open... The algorithm looks to work acourding to this: http://williams.best.vwh.net/sunrise_sunset_algorithm.htm Where one can read the last line to see it is just added... My objection to the way the functions work probably won't make a change list, but it is something to add as a note to the manual becouse it is confusing (At least to me and perhaps more people). [2005-07-13 01:08:22] golf at dds dot nl After re-reading the source in the bug-report I now see that I passed $long and $lat where I should have passed $longitude, $latitude. I changed the code and now every thing seems oke... Sorry for the hassle made by this report but I realy missed this typo. Regards, Golf P.S. I tryd to add a comment to this bugreport (twice) but it didn't show up, so if there are more than one... 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/33671 -- Edit this bug report at http://bugs.php.net/?id=33671edit=1
