#33707 [Asn]: Errors in select statements not reported
ID: 33707
Updated by: [EMAIL PROTECTED]
Reported By: mangst at inventec dot ch
Status: Assigned
Bug Type: PDO related
Operating System: Windows 2000
PHP Version: 5CVS-2005-07-14 (dev)
Assigned To: wez
New Comment:
I don't view this as a bug.
You can't reproduce it? I can.
We report errors when the driver tells us there are errors;
PDO isn't doing anything wrong, per se.
But there was an error, it's just hidden.
This code works fine:
?php
$db = new PDO('oci:dbname=..', '..', '..');
$st = $db-prepare('select blah from dual');
$rs = $st-execute();
var_dump($rs);
var_dump($st-errorInfo());
?
And this doesn't (only with OCI):
?php
$db = new PDO('oci:dbname=..', '..', '..');
$rs = $db-query('select blah from dual');
var_dump($rs);
var_dump($db-errorInfo());
?
This happens because with MySQL it fails on prepare stage, but OCI
passes prepare and fails only while executing the statement, so the
error goes to the statement handle.
Previous Comments:
[2005-07-14 23:58:04] [EMAIL PROTECTED]
I don't view this as a bug. We report errors when the driver tells us
there are errors; PDO isn't doing anything wrong, per se.
I also don't see how copying the errors up from the statement to the
dbh when execute() is called will help either.
[2005-07-14 23:37:35] [EMAIL PROTECTED]
That happens because Oracle's OCIStmtPrepare() doesn't validate the
query, it just allocates/prepares stmt handle for execution. Then PDO
happily executes this statement and all errors go to the stmt handle
(which is destroyed right after that).
Wez, from what I can see, with OCI we should always copy einfo struct
from the stmt handle to the dbh handle if stmt's execution failed.
Thoughts?
[2005-07-14 22:07:02] mangst at inventec dot ch
Description:
When a SQL statement is executed with PDO::query, PDO::errorInfo[0]
always reports 0 even when an error has occurred and PDO::query
returned false.
Reproduce code:
---
?php
try {
$db = new PDO('oci:dbname=***', '***', '***');
} catch (PDOException $e) {
exit (Failed to obtain db handle: . $e-getMessage());
}
$rs = $db-query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo br /\r\nError info of database handle: ;
var_dump($db-errorInfo());
$db = null;
?
Expected result:
Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]= string(5) 42000 [1]=
[2]= string(x) ORA-00904: NVARCHAR: invalid identifier}
Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]= string(5) 0 }
--
Edit this bug report at http://bugs.php.net/?id=33707edit=1
#33709 [Opn-Bgs]: Problems with mail and str_replace
ID: 33709 Updated by: [EMAIL PROTECTED] Reported By: jjohnson at salesteamautomation dot com -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Windows XP PHP Version: 4.4.0 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. Works just fine here. Ask somewhere else what's wrong with your HTML. Previous Comments: [2005-07-15 01:34:42] jjohnson at salesteamautomation dot com This is also a problem with version 4.4.0. [2005-07-15 01:00:47] jjohnson at salesteamautomation dot com Just a note on the above comment. str_replace is what causes corrupted emails. The content looks fine on the sender end, but the receiver end has problems. [2005-07-15 00:58:58] jjohnson at salesteamautomation dot com Here's the shortest script I can create to replicate the bug. The code is not that long, but it seems to be dependent on the data. I shortened the data as much as I could. $breaks = ' htmlhead/headbody DT class=MsoNormal style=MARGIN-LEFT: 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6; tab-stops: list .75inFONT face=Symbol size=2SPAN style=FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: SymbolSPAN style=mso-list: Ignore·FONT face=Times New Roman size=1SPAN style=FONT: 7ptnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; /SPAN/FONT/SPAN/SPAN/FONTSPAN dir=ltrFONT face=Arial color=black size=2SPAN style=FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: ArialPhone only - $1,300 per yearo:p/o:p/SPAN/FONT/SPAN DT class=MsoNormal style=MARGIN-LEFT: 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6; tab-stops: list .75inFONT face=Symbol size=2SPAN style=FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: SymbolSPAN style=mso-list: Ignore·FONT face=Times New Roman size=1SPAN style=FONT: 7ptnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; /SPAN/FONT/SPAN/SPAN/FONTSPAN dir=ltrFONT face=Arial color=black size=2SPAN style=FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: ArialBoth - $1,500 per yearo:p/o:p/SPAN/FONT/SPAN /body/html '; $works = ' htmlhead/headbody DT class=MsoNormal style=MARGIN-LEFT: 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6; tab-stops: list .75inFONT face=Symbol size=2SPAN style=FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: SymbolSPAN style=mso-list: Ignore·FONT face=Times New Roman size=1SPAN style=FONT: 7ptnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; /SPAN/FONT/SPAN/SPAN/FONTSPAN dir=ltrFONT face=Arial color=black size=2SPAN style=FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: ArialPhone only - $1,300 per yearo:p/o:p/SPAN/FONT/SPAN DT class=MsoNormal style=MARGIN-LEFT: 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6; tab-stops: list .75inFONT face=Symbol size=2SPAN style=FONT-SIZE: 10pt; FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; mso-bidi-font-family: SymbolSPAN style=mso-list: Ignore·FONT face=Times New Roman size=1SPAN style=FONT: 7ptnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; /SPAN/FONT/SPAN/SPAN/FONTSPAN dir=ltrFONT face=Arial color=black size=2SPAN style=FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: ArialBoth - $1,500 per yearo:p/o:p/SPAN/FONT/SPAN /body/html '; $breaks = str_replace(\n,'',$breaks); $header = MIME-Version: 1.0\nContent-Type: text/html; charset=iso-8859-1\n; $result = mail([EMAIL PROTECTED], 'breaks', $breaks, $header, ''); $result = mail([EMAIL PROTECTED], 'works', $works, $header, ''); [2005-07-14 23:59:10] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Please provide a *short* and *readable* reproduce script. Thanks. [2005-07-14 23:51:36] jjohnson at salesteamautomation dot com Description: We're having a problem with mail and str_replace. If we use
#33635 [Asn]: couldn't fetch mysqli error when attempting to write session data to db
ID: 33635 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk Status: Assigned Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) Assigned To: georg New Comment: This problem only occurs when writing out session data to a database when the script terminates, and also because I am using a shared database connection (the one created when the session data was forst read in). I conducted a little experiment by replacing the exit function with session_write_close(), and this did not produce the error. I therefore strongly suspect that the order of events at script termination has been altered to: (a) close all resources (b) write session data (to database) This will fail if (b) uses a resource closed in (a) Previous Comments: [2005-07-12 01:08:12] [EMAIL PROTECTED] Assigned to the author of the extension, who can propably explain this better.. [2005-07-11 23:55:55] tony at marston-home dot demon dot co dot uk You are completely mistaken. I am not mixing both OO and procedural ways of accessing the DB - all my calls to the mysqli_* functions are in the procedural style. The fact that I am making these calls inside my own OO class should be totally irrelevant. The same code has worked perfectly through php 5.0.0 to 5.0.4, and with 5.0.5-dev only fails when I try to write my session data to the database. SOMETHING HAS BEEN INTRODUCED IN 5.0.5-dev THAT CAUSES THIS FAILURE. My use of static variables follows the documentation for the singleton pattern at http://www.php.net/manual/en/language.oop5.patterns.php. It allows to to call mysqli_connect() only once for a request. [2005-07-11 22:48:09] [EMAIL PROTECTED] Please read the friendly manual about Mysqli. You're trying to mix both OO and procedural way of accessing the DB. Choose one and stick to that. (And I don't get the idea of making the connection 'static' either..especially if you deal with OOP) [2005-07-11 12:33:45] tony at marston-home dot demon dot co dot uk Whoops. That URL should be http://www.tonymarston.net/test.zip [2005-07-11 11:59:48] tony at marston-home dot demon dot co dot uk I have changed the test set as follows: (a) Everything is in a single file (test.php) (b) I have removed the PHP 4 code (= with objects) (c) I have removed redundant methods. New test set is available at http://www.tonymarston.net/text.zip 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/33635 -- Edit this bug report at http://bugs.php.net/?id=33635edit=1
#33692 [Opn]: imagettftext produces no output
ID: 33692 User updated by: a dot vent at procommerz dot de Reported By: a dot vent at procommerz dot de Status: Open Bug Type: GD related Operating System: Debian Linux 3.0 Woody PHP Version: 4.4.0 New Comment: Additional note: After further dealing with this issue I found that imagettftext works fine on 8 bit images (when using imagecreate instead of imagecreatetruecolor), but not on true color images. There is a workaround proposal published by persa (http://www.webdeveloper.com/forum/showthread.php?threadid=30767) that is to create two images (one of them at 8 bit) and then merging them together after putting the text onto the 8 bit image. It actually seems to be a bug, doesn't it? Best regards, Andreas Previous Comments: [2005-07-14 09:50:28] a dot vent at procommerz dot de Description: The ImageTTFText function produces no result, but also no error. I've tried several font files (Microsoft TT core fonts and also from other sources), several paths (the same dir as the PHP script, relative to DocRoot, absolute path a.s.o.). It looks like not calling imagettftext - the function silently does nothing... I have Debian Woody with Apache 1.3.29 / PHP 4.4.0. The GD lib is the bundled one (phpinfo says: 2.0.28 compatible). The Freetype lib version is 1.4pre, as provided from Debian package manager. PHP configure options: './configure' '--with-apxs=/var/www/bin/apxs' '--with-mysql' '--enable-ftp' '--enable-shared' '--with-iconv' '--with-gd' '--with-curl' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-dom=/usr' '--with-zlib' '--enable-cli' '--with-ttf=/usr' Output snippet from phpinfo: GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Support enabled FreeType Linkage with TTF library GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XBM Support enabled Reproduce code: --- ?php header(Content-type: image/png); $im = imagecreatetruecolor(400, 30); $grey = imagecolorallocate($im, 102, 102, 102); $white = imagecolorallocate($im, 255, 255, 255); $red = imagecolorallocate($im, 255, 0, 0); imagefill($im, 0, 0, $grey); $fontfile = realpath(./Arial.ttf); imagettftext($im, 20, 0, 10, 20, $white, $fontfile, Hello World!); imagepng($im); imagedestroy($im); ? Expected result: Displays an image with white-colored text Hello World in Arial font face on grey background. Actual result: -- Displays an grey-colored image without any text (empty grey box). No error messages. -- Edit this bug report at http://bugs.php.net/?id=33692edit=1
#33708 [Fbk-Opn]: Problem with php module recode
ID: 33708 User updated by: kirameku at email dot cz Reported By: kirameku at email dot cz -Status: Feedback +Status: Open Bug Type: Recode related Operating System: RedHat ES4 x86_64 PHP Version: 4.4.0 New Comment: -- System Information: RedHat ES4 (x86_64) Architecture: x86_64 Kernel: 2.6.9-11.ELsmp I have php4 compiled with ./configure .. --enable-recode --with-recode When I do $ /usr/bin/php ./test.php Segmentation fault and test.php : ? echo recode_string(utf-8..html_4.0,Hello, World !); ? I first tought it was a bug on librecode but it works well from the command line : echo Hello, World|recode utf-8..html_4.0 Hello, World Previous Comments: [2005-07-14 22:22:07] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2005-07-14 22:20:38] kirameku at email dot cz Description: Problem with php module recode on platform x86_64. recode ( string request, string string ) = Segmentation fault. -- Edit this bug report at http://bugs.php.net/?id=33708edit=1
#33704 [Opn-Bgs]: similar to bug#19804
ID: 33704 Updated by: [EMAIL PROTECTED] Reported By: jokar30 at hotmail dot com -Status: Open +Status: Bogus Bug Type: mcrypt related Operating System: sparc solaris 9 PHP Version: 5.0.3 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-14 22:05:35] jokar30 at hotmail dot com Thank you for your reply... That means I should use mcrypt and not libmcrypt? In this case, I should use ./configure' '--with-mcrypt=/opt/mcrypt-x.y.z' '--with-mhash=/opt/php-5.0.4/ext/mhash' '--with-apxs=/usr/apache/bin/apxs' ??? [2005-07-14 21:27:49] [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. And it doesn't make sense, as mcrypt now has all their modules builtin anyway so you don't need those directores. I guess you installed libmcrypt incorrectly. [2005-07-14 20:05:50] jokar30 at hotmail dot com Description: Hello, I have done nearly everything and I still get the supported ciphers and supported modes = none on the phpinfo(). I have set mcrypt.algorithms_dir = /opt/libmcrypt-2.5.6/modules/algorithms/ mcrypt.modes_dir = /opt/libmcrypt-2.5.6/modules/modes/ I have changed the chmod 755 to /usr/local/lib/libmcrypt I have cofigured php5.0.4 with ./configure' '--with-mcrypt=/opt/libmcrypt-2.5.6' '--with-mhash=/opt/php-5.0.4/ext/mhash' '--with-apxs=/usr/apache/bin/apxs' Any help would be appreciated ;-) Thank you -- Edit this bug report at http://bugs.php.net/?id=33704edit=1
#33698 [Opn-Bgs]: Conflicts with multiple interfaces sharing common method names
ID: 33698
Updated by: [EMAIL PROTECTED]
Reported By: jason at hybd dot net
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.0.4
New Comment:
PHP != Java
Previous Comments:
[2005-07-14 17:35:15] jason at hybd dot net
Description:
This is debateable if this is a bug or not. Personally, I don't regard
it as a bug.
Classes that implement 1 interface that share common methods raise
fatal errors. Because of the abstract nature of interfaces, no error or
warning should be rasied.
I know PHP Java, but Java doesn't raise any errors, and PHP5's OO
model is very close to Java's
Reproduce code:
---
interface FirstInterface
{
function execute();
}
interface SecondInterface
{
function execute();
}
class MyClass implements FirstInterface, SecondInterface
{
function execute()
{
echo Hello World;
}
}
$obj = new MyClass();
$obj-execute();
Expected result:
Hello World
Actual result:
--
Can't inherit abstract function SecondInterface::execute()
--
Edit this bug report at http://bugs.php.net/?id=33698edit=1
#31132 [Com]: Installing PHP 5.0.3 causes 403.9 HTTP Errors under IIS 5
ID: 31132 Comment by: webwire at zonnet dot nl Reported By: aaron at visualprose dot com Status: No Feedback Bug Type: IIS related Operating System: Windows XP Professional SP 1 PHP Version: 5.0.3 New Comment: I can confirm: The problem is solved on the newest CVS version. Previous Comments: [2005-03-15 18:03:19] mailkabin at yahoo dot com Can't Configure the PHP version 5.0 in Win2003 System. .. Operation System : Windows Server 2003 IIS Ver : 6.0 Other Installed Comp: ASP / ASP .net . Problem : Displays the Page Cannot be displayed Page. or File Not Found Page. [2005-03-10 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-02-28 21:14: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 [2004-12-16 18:49:38] aaron at visualprose dot com Description: When PHP 5.0.3 is installed under IIS 5.0 on Windows XP Professional, all web pages (.html, .php, .asp, or .aspx) can only be viewed ten times before IIS reports HTTP 403.9 - Access Forbidden: Too many users are connected. No pages (inlcluding HTML, ASP, etc.) can be viewed once this error occurs. IIS must be restarted (which takes approximately 5 minutes). I have followed the steps on Microsoft's site to disable HTTP Keep-alives, and the problem persists. Removing the script map to PHP solves the problem, which is what leads me to believe PHP is causing the problem Reproduce code: --- 1) Install PHP 5.0.3 on Windows XP SP 1. 2) Load up a .html, .php, or .asp running on the web server. 3) Hit Refresh 10 times. 4) Note the 403.9 HTTP error appears. Note that IIS must be restarted before access to any resource is allowed again. Expected result: No 403.9 error. Actual result: -- IIS continues to give the 403.9 error page until it is restarted. -- Edit this bug report at http://bugs.php.net/?id=31132edit=1
#33648 [Csd-Asn]: Using --with-regex=system causes compile failure
ID: 33648
Updated by: [EMAIL PROTECTED]
Reported By: ergin at ergin dot dyndns dot org
-Status: Closed
+Status: Assigned
Bug Type: Compile Failure
Operating System: *
PHP Version: 5CVS, 4CVS (2005-07-12)
Assigned To: andrei
New Comment:
This is not fixed yet. I added the necessary configure checks
and now HAVE_REGEX_T_RE_MAGIC is defined if re_magic exists in regext_t
struct.
Andrei: Please check it out.
Previous Comments:
[2005-07-14 22:25:38] [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.
[2005-07-12 15:41:55] [EMAIL PROTECTED]
Assigned to Andrei, he broke it.
As to the problem: remove --with-regex=system from your configure line
and it will work fine.
[2005-07-12 08:56:25] ergin at ergin dot dyndns dot org
Here is my configure line...
- START -
%configure \
--prefix=%{_prefix} \
--with-config-file-path=%{_sysconfdir} \
--enable-force-cgi-redirect \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-dom=shared \
--with-bz2 \
--with-db3 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-gd \
--with-gdbm \
--with-gettext \
--with-gmp \
--with-jpeg-dir=%{_prefix} \
--with-mm \
--with-openssl \
--with-png \
--with-regex=system \
--with-ttf \
--with-xml \
--with-expat-dir=%{_prefix} \
--with-zlib \
--with-layout=GNU \
--enable-bcmath \
--enable-debugger \
--enable-ftp \
--enable-magic-quotes \
--enable-safe-mode \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-discard-path \
--enable-mime-magic \
--enable-track-vars \
--enable-trans-sid \
--enable-yp \
--enable-wddx \
--without-oci8 \
--with-iconv --enable-mbstring --enable-mbregex \
--with-imap=shared,/usr/local/src/imap-2002e --with-imap-ssl
--with-kerberos=/usr/kerberos \
--with-ldap=shared \
--with-mysql=shared,/usr \
--with-pgsql=shared \
--with-curl=shared \
--with-mcrypt=shared \
--with-snmp=%{_prefix} \
--with-snmp=shared \
--enable-ucd-snmp-hack \
--with-unixODBC=shared \
--with-xmlrpc=shared \
--with-mhash=shared \
--enable-memory-limit \
--enable-bcmath \
--enable-shmop \
--enable-versioning \
--enable-sockets --enable-pcntl --enable-sigchild \
$*
END --
[2005-07-11 22:38:14] ergin at ergin dot dyndns dot org
Description:
Got following message when I tried to build RPMS for new PHP version
php-4.4.0 (OBS!!! couldn't choose it from drop menu - PHP version)
.
Actual result:
--
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c: In fucntion
'_php_regcomp':
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:53 structure has no
member named 're_magic'
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:72 structure has no
member named 're_magic'
make *** [ext/standard/reg.lo] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.66063
--
Edit this bug report at http://bugs.php.net/?id=33648edit=1
#33707 [Asn]: Errors in select statements not reported
ID: 33707
Updated by: [EMAIL PROTECTED]
Reported By: mangst at inventec dot ch
Status: Assigned
Bug Type: PDO related
Operating System: Windows 2000
PHP Version: 5CVS-2005-07-14 (dev)
Assigned To: wez
New Comment:
Ah, I misread the report. PDO::query() should report an error here of
course.
Previous Comments:
[2005-07-15 08:20:07] [EMAIL PROTECTED]
I don't view this as a bug.
You can't reproduce it? I can.
We report errors when the driver tells us there are errors;
PDO isn't doing anything wrong, per se.
But there was an error, it's just hidden.
This code works fine:
?php
$db = new PDO('oci:dbname=..', '..', '..');
$st = $db-prepare('select blah from dual');
$rs = $st-execute();
var_dump($rs);
var_dump($st-errorInfo());
?
And this doesn't (only with OCI):
?php
$db = new PDO('oci:dbname=..', '..', '..');
$rs = $db-query('select blah from dual');
var_dump($rs);
var_dump($db-errorInfo());
?
This happens because with MySQL it fails on prepare stage, but OCI
passes prepare and fails only while executing the statement, so the
error goes to the statement handle.
[2005-07-14 23:58:04] [EMAIL PROTECTED]
I don't view this as a bug. We report errors when the driver tells us
there are errors; PDO isn't doing anything wrong, per se.
I also don't see how copying the errors up from the statement to the
dbh when execute() is called will help either.
[2005-07-14 23:37:35] [EMAIL PROTECTED]
That happens because Oracle's OCIStmtPrepare() doesn't validate the
query, it just allocates/prepares stmt handle for execution. Then PDO
happily executes this statement and all errors go to the stmt handle
(which is destroyed right after that).
Wez, from what I can see, with OCI we should always copy einfo struct
from the stmt handle to the dbh handle if stmt's execution failed.
Thoughts?
[2005-07-14 22:07:02] mangst at inventec dot ch
Description:
When a SQL statement is executed with PDO::query, PDO::errorInfo[0]
always reports 0 even when an error has occurred and PDO::query
returned false.
Reproduce code:
---
?php
try {
$db = new PDO('oci:dbname=***', '***', '***');
} catch (PDOException $e) {
exit (Failed to obtain db handle: . $e-getMessage());
}
$rs = $db-query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo br /\r\nError info of database handle: ;
var_dump($db-errorInfo());
$db = null;
?
Expected result:
Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]= string(5) 42000 [1]=
[2]= string(x) ORA-00904: NVARCHAR: invalid identifier}
Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]= string(5) 0 }
--
Edit this bug report at http://bugs.php.net/?id=33707edit=1
#33698 [Bgs]: Conflicts with multiple interfaces sharing common method names
ID: 33698
User updated by: jason at hybd dot net
Reported By: jason at hybd dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.4
New Comment:
I know PHP != Java, but surely this sort of stuff should be documented?
Most people will expect interfaces to work like Java interfaces or C++
interfaces (Pure virtual abstract methods), as many other languages
seem to follow this behaviour. As I said this is debatable as it
depends how you look at things, and likewise it is fairly easy to work
round this issue.
Previous Comments:
[2005-07-15 12:44:04] [EMAIL PROTECTED]
PHP != Java
[2005-07-14 17:35:15] jason at hybd dot net
Description:
This is debateable if this is a bug or not. Personally, I don't regard
it as a bug.
Classes that implement 1 interface that share common methods raise
fatal errors. Because of the abstract nature of interfaces, no error or
warning should be rasied.
I know PHP Java, but Java doesn't raise any errors, and PHP5's OO
model is very close to Java's
Reproduce code:
---
interface FirstInterface
{
function execute();
}
interface SecondInterface
{
function execute();
}
class MyClass implements FirstInterface, SecondInterface
{
function execute()
{
echo Hello World;
}
}
$obj = new MyClass();
$obj-execute();
Expected result:
Hello World
Actual result:
--
Can't inherit abstract function SecondInterface::execute()
--
Edit this bug report at http://bugs.php.net/?id=33698edit=1
#29724 [Com]: PHP Encountered an Access Violation
ID: 29724
Comment by: andrej at seznam dot org
Reported By: bojo at gvea dot com
Status: No Feedback
Bug Type: Reproducible crash
Operating System: Windows 2003 Server
PHP Version: 5.0.1
New Comment:
This error is following me on 3 different server configs, from php 4
version on. I encountered this error on combination of:
- Windows server (XP, 2000 server, 2003 server)
- IIS 5.0, 5.1 and 6.0
- PHP from 4 to latest 5.1.0b2
- MySQL from versions 4.0.x to latest 5.0.7 beta3
Finally, I was able to reproduce the bug and eliminate it! But only in
one single case:
This PHP code produced Access Violation; It is only weird, that the
EXACT THE SAME code worked without problems for months, but then,
suddenly, it begins constantly producing Access Violation error:
for($i=0;$i$rows;$i++) {
$sqls=UPDATE sms_log SET delivered_date=\$delivered_date[$i]\,
send_date=\$send_date[$i]\, delivered_status=\$state[$i]\ WHERE
msg_id=\$msg_id[$i]\ AND to_user RLIKE $to_user[$i];
$rs=mysql_query($sqls);
}
Now, I only changed the UPDATE to UPDATE LOW_PRIORITY, and Error was
gone! Notise the only difference of UPDATE priorite switch:
for($i=0;$i$rows;$i++) {
$sqls=UPDATE LOW_PRIORITY sms_log SET
delivered_date=\$delivered_date[$i]\, send_date=\$send_date[$i]\,
delivered_status=\$state[$i]\ WHERE msg_id=\$msg_id[$i]\ AND
to_user RLIKE $to_user[$i];
$rs=mysql_query($sqls);
}
The only concern I have is that the whole loop of queries took quite a
long time to execute, even if they were executed in some other PHP
application. I did tests with phpMyAdmin program, and inserted the
whole bunch of about 50 queries from the mentioned loop into SQL query
textbox. It took around a minute to execute!
BUT
if I executed the SAME bunch of queries from the command prompt,
directly to MySQL, it executed in a second!
THEREFORE it is NOT MySQL issue, but is related to how PHP executes
MySQL statements. It might me php_mysql.dll library, might be
libmysql.dll, or PHP core itself.
Hope this would help with determining the cause of this wide spread and
unpredictable error.
Previous Comments:
[2004-09-04 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2004-08-18 02:29:50] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2004-08-18 00:44:45] bojo at gvea dot com
Description:
The original bug found in PHP 5.0.0, referenced here:
http://bugs.php.net/bug.php?id=29127 was never actually resolved.
PHP 5.0.1 continues to give the following error under IIS 6.0 on
Windows 2003 Server: PHP has encountered an Access Violation at [random
memory address].
Expected result:
Page processes completely.
Actual result:
--
Program bails with the following error: PHP has encountered an Access
Violation at [random memory address]
--
Edit this bug report at http://bugs.php.net/?id=29724edit=1
#33671 [Bgs-Opn]: sun_rise and sun_set don't return a GMT timestamp if one passes an offset
ID: 33671 User updated by: golf at dds dot nl Reported By: golf at dds dot nl -Status: Bogus +Status: Open Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.0.4 New Comment: 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 Previous Comments: [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 07:02:02 sunsetOffical = Jul 12 2005 19:09:17 sunsetAstro = Jul 12 2005 20:23:27 Actual result: -- Local Tenerife time sunriseAstro = Jul 12 2005 06:47:50 sunriseOffical = Jul 12 2005 08:02:02 sunsetOffical = Jul 12 2005 20:09:17 sunsetAstro = Jul 12 2005 21:23:27 -- Edit this bug report at http://bugs.php.net/?id=33671edit=1
#33710 [NEW]: ArrayAccess objects doen't initialize $this
From: pornel at despammed dot com
Operating system: all
PHP version: 5.1.0b2
PHP Bug Type: Class/Object related
Bug description: ArrayAccess objects doen't initialize $this
Description:
In object that implements ArrayAccess and accesses itself as array inside
its own method, $this is not available (Undefined variable: this)
Reproduce code:
---
?php
class Foo implements ArrayAccess
{
function offsetExists ($offset) {/*...*/}
function offsetGet ($offset) {/*...*/}
function offsetSet ($offset, $value) {/*...*/}
function offsetUnset ($offset) {/*...*/}
function fail()
{
$this['blah'];
}
function succeed()
{
$this;
$this['blah'];
}
}
$bar = new Foo();
$bar-succeed();
$bar-fail();
Expected result:
No error. Both methods should work.
Actual result:
--
Notice: Undefined variable: this in c:\www\test.php5 on line 13
--
Edit bug report at http://bugs.php.net/?id=33710edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33710r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33710r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33710r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33710r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33710r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33710r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33710r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33710r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33710r=support
Expected behavior: http://bugs.php.net/fix.php?id=33710r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33710r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33710r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33710r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33710r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33710r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33710r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33710r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33710r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33710r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33710r=mysqlcfg
#33671 [Opn-Asn]: sun_rise and sun_set don't return a GMT timestamp if one passes an offset
ID: 33671 Updated by: [EMAIL PROTECTED] Reported By: golf at dds dot nl -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Linux Debian PHP Version: 5.0.4 -Assigned To: +Assigned To: derick 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 07:02:02 sunsetOffical = Jul 12 2005 19:09:17 sunsetAstro = Jul 12 2005 20:23:27 Actual result: -- Local Tenerife time sunriseAstro = Jul 12 2005 06:47:50 sunriseOffical = Jul 12 2005 08:02:02 sunsetOffical = Jul 12 2005 20:09:17 sunsetAstro = Jul 12 2005 21:23:27 -- Edit this bug report at http://bugs.php.net/?id=33671edit=1
#33711 [NEW]: unset() doesn't destroy object with internal references
From: mike dot hall at twistdigital dot co dot uk Operating system: FreeBSD PHP version: 5.1.0b2 PHP Bug Type: Class/Object related Bug description: unset() doesn't destroy object with internal references Description: PHP doesn't unset an object if it contains variables that include references to itself. Despite being unset, the objects remain in memory until the end of the request. This can lead to scripts consuming large amounts of memory when larger and more complex objects are being employed. Reproduce code: --- http://www.indelible.org.uk/reproduce.php Expected result: 0 Create A Create B Destroying B Destroying A 1 Create A Create B Destroying B Destroying A 2 Create A Create B Destroying B Destroying A End of Loop Actual result: -- 0 Create A Create B 1 Create A Create B 2 Create A Create B End of Loop Destroying A Destroying B Destroying A Destroying B Destroying A Destroying B -- Edit bug report at http://bugs.php.net/?id=33711edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33711r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33711r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33711r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33711r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33711r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33711r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33711r=needscript Try newer version: http://bugs.php.net/fix.php?id=33711r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33711r=support Expected behavior: http://bugs.php.net/fix.php?id=33711r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33711r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33711r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33711r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33711r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33711r=dst IIS Stability: http://bugs.php.net/fix.php?id=33711r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33711r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33711r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33711r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33711r=mysqlcfg
#33712 [NEW]: Unable to connect to Oracle database(ORA-12705)
From: lionel dot roux at bio-rad dot com Operating system: AIX5.2 PHP version: 4.4.0 PHP Bug Type: OCI8 related Bug description: Unable to connect to Oracle database(ORA-12705) Description: hello, I have the following messages using : $id=OCILogon(dtpfra,dtpfra,$db,$NLS_LANG); Warning: ocilogon(): OCISessionBegin: Error while trying to retrieve text for error ORA-12705 in /usr/local/apache2/htdocs/fonctions.php on line 27 testconn=-1 The following parameters have been set in envars: export ORA_NLS32=/home/oracle/9.2.0/ocommon/nls/admin/data export LIBPATH=/home/oracle/9.2.0/lib32:/usr/local/apache2/lib:$LIBPATH export LD_LIBRARY_PATH=/home/oracle/9.2.0/lib:/home/oracle/9.2.0/lib32 export ORACLE_BASE=/home/oracle export ORACLE_HOME=$ORACLE_HOME:/home/oracle/9.2.0 export TNS_ADMIN=$ORACLE_HOME/network/admin:$TNS_ADMIN export NLS_LANG=american_america.WE8ISO8859P1 export LANG=C #export LANG=en_US export TWO_TASK=$ORACLE_HOME Reproduce code: --- putenv(ORACLE_SID=DLPFRA); getenv(ORACLE_HOME); getenv(TNS_ADMIN); getenv(LD_LIBRARY_PATH); $ORACLE_SID = getenv(ORACLE_SID); $ORACLE_HOME = getenv(ORACLE_HOME); $LD_LIBRARY_PATH=getenv(LD_LIBRARY_PATH); $TNS_ADMIN=getenv(TNS_ADMIN); $NLS_LANG=getenv(NLS_LANG); $LANG=getenv(LANG); print VERIF :$ORACLE_SID, $ORACLE_HOME, $LD_LIBRARY_PATH, $TNS_ADMIN, $NLS_LANG; $db=(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP) (HOST=FRUX33)(PORT=1521) ) ) (CONNECT_DATA=(SERVICE_NAME=dtpfra)) ); $id=OCILogon(dtpfra,dtpfra,$db,$NLS_LANG); Expected result: Connection to the database Actual result: -- VERIF :DLPFRA, :/home/oracle/9.2.0, /home/oracle/9.2.0/lib:/home/oracle/9.2.0/lib32, :/home/oracle/9.2.0/network/admin:, american_america.WE8ISO8859P1 Warning: ocilogon(): OCISessionBegin: Error while trying to retrieve text for error ORA-12705 in /usr/local/apache2/htdocs/fonctions.php on line 27 -- Edit bug report at http://bugs.php.net/?id=33712edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33712r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33712r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33712r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33712r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33712r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33712r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33712r=needscript Try newer version: http://bugs.php.net/fix.php?id=33712r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33712r=support Expected behavior: http://bugs.php.net/fix.php?id=33712r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33712r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33712r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33712r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33712r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33712r=dst IIS Stability: http://bugs.php.net/fix.php?id=33712r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33712r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33712r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33712r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33712r=mysqlcfg
#33713 [NEW]: Foreach uses the same internal pointer in different iterations of recursive fns
From: bmorel at ssi dot fr
Operating system: Fedora Core 4
PHP version: 5.0.4
PHP Bug Type: Scripting Engine problem
Bug description: Foreach uses the same internal pointer in different
iterations of recursive fns
Description:
Sorry if this is not a bug, but I think the behavior is not normal, even
after searching the net and this bug database.
It seems that, used inside a recursive function, foreach doesn't use
different array pointers for each iteration of the function, but uses the
same at each time. This common pointer is reseted at each foreach() call.
Reproduce code:
---
function recurse($doRecurse = true) {
static $array = array(1,2);
foreach ($array as $value) {
echo $value . PHP_EOL;
if ($doRecurse) recurse(false);
}
}
recurse();
Expected result:
1
1
2
2
1
2
Actual result:
--
1
1
2
--
Edit bug report at http://bugs.php.net/?id=33713edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33713r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33713r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33713r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33713r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33713r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33713r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33713r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33713r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33713r=support
Expected behavior: http://bugs.php.net/fix.php?id=33713r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33713r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33713r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33713r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33713r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33713r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33713r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33713r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33713r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33713r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33713r=mysqlcfg
#33714 [NEW]: Segmentation fault on interactive mode
From: dev at null dot com
Operating system: Redhat 9
PHP version: 5.0.4
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault on interactive mode
Description:
php -a
?
$tmpfiles = scandir('/tmp');
foreach ($tmpfiles as $tmpfile) {
}
Segmentation fault
Reproduce code:
---
php -a
?
$tmpfiles = scandir('/tmp');
foreach ($tmpfiles as $tmpfile) {
}
Segmentation fault
Actual result:
--
Segmentation fault.
--
Edit bug report at http://bugs.php.net/?id=33714edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33714r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33714r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33714r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33714r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33714r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33714r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33714r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33714r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33714r=support
Expected behavior: http://bugs.php.net/fix.php?id=33714r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33714r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33714r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33714r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33714r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33714r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33714r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33714r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33714r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33714r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33714r=mysqlcfg
#33714 [Opn-Fbk]: Segmentation fault on interactive mode
ID: 33714
Updated by: [EMAIL PROTECTED]
Reported By: dev at null dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Redhat 9
PHP Version: 5.0.4
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Previous Comments:
[2005-07-15 18:48:41] dev at null dot com
Description:
php -a
?
$tmpfiles = scandir('/tmp');
foreach ($tmpfiles as $tmpfile) {
}
Segmentation fault
Reproduce code:
---
php -a
?
$tmpfiles = scandir('/tmp');
foreach ($tmpfiles as $tmpfile) {
}
Segmentation fault
Actual result:
--
Segmentation fault.
--
Edit this bug report at http://bugs.php.net/?id=33714edit=1
#33715 [NEW]: cant use php4 with memory-limit
From: excedor at gmail dot com Operating system: linux PHP version: 4.4.0 PHP Bug Type: *Configuration Issues Bug description: cant use php4 with memory-limit Description: When I try to run php4.4.0 with this configuration: ./configure --with-apxs2=/usr/local/httpd/bin/apxs --with-mysql --prefix=/usr/local/php4 --with-libxml-dir=/usr/lib --with-zlib --with-mysql=/usr/local/mysql --enable-soap --enable-sockets --with-gettext --enable-mbstring --with-gd --with-jpeg-dir=/usr/lib --enable-memory-limit i get at SOME websites following message: Bad Gateway The proxy server received an invalid response from an upstream server. Most of the sites are working - just one drupal version does not appear (i have the same drupalversion in different directories and the other are working, but they are not as complex and filled with content like the notworking version) I didn't find the problem. I know how to compile and to get it run, so that's not the problem. When I run the same configuration without the enable-memory-limit parameter everything works perfectly (but i need memory_get_usage for some reasons, and it's only available with that parameter) is it a bug or what could be the reason? With php5 it's working but i would have to modify a LOT of things, so i would really prefer to use php4. Reproduce code: --- ./configure --with-apxs2=/usr/local/httpd/bin/apxs --with-mysql --prefix=/usr/local/php4 --with-libxml-dir=/usr/lib --with-zlib --with-mysql=/usr/local/mysql --enable-soap --enable-sockets --with-gettext --enable-mbstring --with-gd --with-jpeg-dir=/usr/lib --enable-memory-limit Expected result: The website... http://www.humano2.org Actual result: -- Bad Gateway The proxy server received an invalid response from an upstream server. -- Edit bug report at http://bugs.php.net/?id=33715edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33715r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33715r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33715r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33715r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33715r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33715r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33715r=needscript Try newer version: http://bugs.php.net/fix.php?id=33715r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33715r=support Expected behavior: http://bugs.php.net/fix.php?id=33715r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33715r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33715r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33715r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33715r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33715r=dst IIS Stability: http://bugs.php.net/fix.php?id=33715r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33715r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33715r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33715r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33715r=mysqlcfg
#33711 [Opn-Bgs]: unset() doesn't destroy object with internal references
ID: 33711 Updated by: [EMAIL PROTECTED] Reported By: mike dot hall at twistdigital dot co dot uk -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: FreeBSD PHP Version: 5.1.0b2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2005-07-15 16:50:41] mike dot hall at twistdigital dot co dot uk Description: PHP doesn't unset an object if it contains variables that include references to itself. Despite being unset, the objects remain in memory until the end of the request. This can lead to scripts consuming large amounts of memory when larger and more complex objects are being employed. Reproduce code: --- http://www.indelible.org.uk/reproduce.php Expected result: 0 Create A Create B Destroying B Destroying A 1 Create A Create B Destroying B Destroying A 2 Create A Create B Destroying B Destroying A End of Loop Actual result: -- 0 Create A Create B 1 Create A Create B 2 Create A Create B End of Loop Destroying A Destroying B Destroying A Destroying B Destroying A Destroying B -- Edit this bug report at http://bugs.php.net/?id=33711edit=1
#33713 [Opn-Bgs]: Foreach uses the same internal pointer in different iterations of recursive fns
ID: 33713
Updated by: [EMAIL PROTECTED]
Reported By: bmorel at ssi dot fr
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
-Operating System: Fedora Core 4
+Operating System: *
-PHP Version: 5.0.4
+PHP Version: 5.*
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Use ArrayObject/ArrayIterator instead or as a wrapper around your
arrays.
Previous Comments:
[2005-07-15 18:41:52] bmorel at ssi dot fr
Description:
Sorry if this is not a bug, but I think the behavior is not normal,
even after searching the net and this bug database.
It seems that, used inside a recursive function, foreach doesn't use
different array pointers for each iteration of the function, but uses
the same at each time. This common pointer is reseted at each foreach()
call.
Reproduce code:
---
function recurse($doRecurse = true) {
static $array = array(1,2);
foreach ($array as $value) {
echo $value . PHP_EOL;
if ($doRecurse) recurse(false);
}
}
recurse();
Expected result:
1
1
2
2
1
2
Actual result:
--
1
1
2
--
Edit this bug report at http://bugs.php.net/?id=33713edit=1
#33716 [NEW]: HTTP authentication
From: jacka at torreycommerce dot com
Operating system: linux
PHP version: 5.0.4
PHP Bug Type: SOAP related
Bug description: HTTP authentication
Description:
It appears that the constructor of SoapClient is completely ignoring the
second argument (options). I am trying to use basic http authentication,
but regardless of what I send as the options parameter I get the same
result.
Reproduce code:
---
$woptions['soap_version']=SOAP_1_2;
$woptions['login']=;
$woptions['password']=;
$client = new
SoapClient(http://wsdl_that_uses_basic_HTTP_auth,$woptions);
Expected result:
It should return no errors or warnings.
Actual result:
--
PHP Warning:
SoapClient::__construct(http://wsdl_that_uses_basic_HTTP_auth): failed to
open stream: HTTP request failed! HTTP/1.1 401 Authorization Required
in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8
PHP Warning: I/O warning : failed to load HTTP resource in
/var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8
PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://merchant-api-qa.amazon.com/gateway/merchant-interface-mime' in
/var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on line 8
PHP Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from 'http://wsdl_that_uses_basic_HTTP_auth' in
/var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php:8
Stack trace:
#0 /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php(8):
SoapClient-__construct('http://wsdl_that_uses_basic_HTTP_auth', Array)
#1 {main}
thrown in /var/www/html/engine_cvs/misc_scripts/amazon/soaptest.php on
line 8
--
Edit bug report at http://bugs.php.net/?id=33716edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33716r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33716r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33716r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33716r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33716r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33716r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33716r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33716r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33716r=support
Expected behavior: http://bugs.php.net/fix.php?id=33716r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33716r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33716r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33716r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33716r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33716r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33716r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33716r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33716r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33716r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33716r=mysqlcfg
#33717 [NEW]: crash 'apache' when a query contain ':memory:'
From: fhenninot at freesurf dot fr
Operating system: Linux
PHP version: 5.1.0b2
PHP Bug Type: PDO related
Bug description: crash 'apache' when a query contain ':memory:'
Description:
This is a bug, i think, in PHP-5.1B3
When i search a string named ':memory:' into a database field, this crash
apache with the message : [Fri Jul 15 20:17:11 2005] [notice] child pid
11338 exit signal Segmentation fault (11)
I can test it on linux only! and with some apache version.
Reproduce code:
---
?php
$PDO_DB = new
PDO('sqlite:/usr/local/apache2/htdocs/SQLiteManager-1.1.2CVS/include/config3.db',
'', '');
$res = $PDO_DB-query(SELECT * FROM database WHERE location like
':memory:');
--
Edit bug report at http://bugs.php.net/?id=33717edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33717r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33717r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33717r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33717r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33717r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33717r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33717r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33717r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33717r=support
Expected behavior: http://bugs.php.net/fix.php?id=33717r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33717r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33717r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33717r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33717r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33717r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33717r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33717r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33717r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33717r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33717r=mysqlcfg
#33717 [Opn-Asn]: crash 'apache' when a query contain ':memory:'
ID: 33717
Updated by: [EMAIL PROTECTED]
Reported By: fhenninot at freesurf dot fr
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Linux
-PHP Version: 5.1.0b2
+PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: wez
New Comment:
Sounds like a pretty nasty problem to me.
Previous Comments:
[2005-07-15 23:01:05] fhenninot at freesurf dot fr
Description:
This is a bug, i think, in PHP-5.1B3
When i search a string named ':memory:' into a database field, this
crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice]
child pid 11338 exit signal Segmentation fault (11)
I can test it on linux only! and with some apache version.
Reproduce code:
---
?php
$PDO_DB = new
PDO('sqlite:/usr/local/apache2/htdocs/SQLiteManager-1.1.2CVS/include/config3.db',
'', '');
$res = $PDO_DB-query(SELECT * FROM database WHERE location like
':memory:');
--
Edit this bug report at http://bugs.php.net/?id=33717edit=1
#33717 [Asn]: crash 'apache' when a query contain ':memory:'
ID: 33717
Updated by: [EMAIL PROTECTED]
Reported By: fhenninot at freesurf dot fr
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.0b3
Assigned To: wez
New Comment:
BTW, if you want a workaround, you can use parameters like this:
$stmt = $db-prepare(SELECT * from database where location like ?);
$stmt-execute(array(:memory));
Previous Comments:
[2005-07-15 23:30:54] [EMAIL PROTECTED]
Sounds like a pretty nasty problem to me.
[2005-07-15 23:01:05] fhenninot at freesurf dot fr
Description:
This is a bug, i think, in PHP-5.1B3
When i search a string named ':memory:' into a database field, this
crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice]
child pid 11338 exit signal Segmentation fault (11)
I can test it on linux only! and with some apache version.
Reproduce code:
---
?php
$PDO_DB = new
PDO('sqlite:/usr/local/apache2/htdocs/SQLiteManager-1.1.2CVS/include/config3.db',
'', '');
$res = $PDO_DB-query(SELECT * FROM database WHERE location like
':memory:');
--
Edit this bug report at http://bugs.php.net/?id=33717edit=1
#33717 [Asn]: crash 'apache' when a query contain ':memory:'
ID: 33717
Updated by: [EMAIL PROTECTED]
Reported By: fhenninot at freesurf dot fr
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.0b3
Assigned To: wez
New Comment:
Doh. Like this:
$stmt = $db-prepare(SELECT * from database where location like ?);
$stmt-execute(array(:memory:));
Previous Comments:
[2005-07-15 23:32:41] [EMAIL PROTECTED]
BTW, if you want a workaround, you can use parameters like this:
$stmt = $db-prepare(SELECT * from database where location like ?);
$stmt-execute(array(:memory));
[2005-07-15 23:30:54] [EMAIL PROTECTED]
Sounds like a pretty nasty problem to me.
[2005-07-15 23:01:05] fhenninot at freesurf dot fr
Description:
This is a bug, i think, in PHP-5.1B3
When i search a string named ':memory:' into a database field, this
crash apache with the message : [Fri Jul 15 20:17:11 2005] [notice]
child pid 11338 exit signal Segmentation fault (11)
I can test it on linux only! and with some apache version.
Reproduce code:
---
?php
$PDO_DB = new
PDO('sqlite:/usr/local/apache2/htdocs/SQLiteManager-1.1.2CVS/include/config3.db',
'', '');
$res = $PDO_DB-query(SELECT * FROM database WHERE location like
':memory:');
--
Edit this bug report at http://bugs.php.net/?id=33717edit=1
#33718 [NEW]: Problems with Java PHP integration
From: tuta at digi dot com dot br
Operating system: Windows 2000
PHP version: 5.0.4
PHP Bug Type: Java related
Bug description: Problems with Java PHP integration
Description:
Hi All,
I just downloaded(few hours ago) PHP 5.04 for Windows
(php-5.0.4-Win32.zip) + PECL(pecl-5.0.4-Win32.zip),
and i was trying to make PHP and talk with some of my Java Classes. I
created some simple files just to start, something like this:
PHP
Filename : java.php
?
$j = new Java(Hello);
print $j-hello(All);
?
Java:
Filename: Hello.java
class Hello {
public String hello(String name) {
return Hello + name + , how are you?;
}
}
Here is my php.ini
[java]
java.class.path= c:\php\ext\php_java.jar;c:\php\ext;c:\java_classes
java.home= C:\jdk1.5.0\jre\bin\
java.library.path= c:\php\ext
java.library= C:\jdk1.5.0\jre\bin\server\jvm.dll
When i tried to run my java.php on my Apache Server(2.0.53 Win32), my
web browser(FireFox) showed me the message The Document Contains no
Data, and i
found many messages Parent: child process exited with status 3221225477
-- Restarting. on my Apache's log file.
I also tried to run java.php from console(using php.exe java.php) ,
but without any success and without any error message, the php.exe just
jump to another
line without complains. So, i tried to spy the process using some debug
tools to figure it out what was the problem, and i found it inside
php_java.jar
file and here it is:
- There is a little space after the name php_java in the file
reflect.properties(line library=php_java), and when the reflect.class
tries to find
the lib.( System.loadLibrary(bundle.getString(library) -- reflect.java
); it will always look for php_java .dll(with space!). I fixed manually
my reflect.properties and
everything is fine now. I hope this information could help someone with
the same problem.
Best Regards,
Tuta Muniz
--
Edit bug report at http://bugs.php.net/?id=33718edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33718r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33718r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33718r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33718r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33718r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33718r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33718r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33718r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33718r=support
Expected behavior: http://bugs.php.net/fix.php?id=33718r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33718r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33718r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33718r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33718r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33718r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33718r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33718r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33718r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33718r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33718r=mysqlcfg
#33719 [NEW]: foreach clash
From: s dot masugata at digicom dot dnp dot co dot jp
Operating system: Solaris8
PHP version: 4.4.0
PHP Bug Type: *General Issues
Bug description: foreach clash
Description:
KEY and VALUE of foreach are made the duplicate variable, strange
operation is
done.
Reproduce code:
---
?php
$arr = array(1,123,12345);
foreach ( $arr as $val = $val ) {
// echo debug {$val}\n;
// this comment is removed, stranger operation is done.
}
print_r( $arr );
?
Expected result:
Array
(
[0] = 1
[1] = 123
[2] = 12345
)
Actual result:
--
Array
(
[0] = 1
[1] = 2
[2] =
)
/usr/local/src/php-4.4.0/Zend/zend_execute.c(2436) : Freeing 0x0838B164
(12 bytes), script=f.php
--
Edit bug report at http://bugs.php.net/?id=33719edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33719r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33719r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33719r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33719r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33719r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33719r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33719r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33719r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33719r=support
Expected behavior: http://bugs.php.net/fix.php?id=33719r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33719r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33719r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33719r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33719r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33719r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33719r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33719r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33719r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33719r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33719r=mysqlcfg
#33720 [NEW]: mb_encode_mimeheader does not work
From: s dot masugata at digicom dot dnp dot co dot jp Operating system: Solaris8 PHP version: 4.4.0 PHP Bug Type: mbstring related Bug description: mb_encode_mimeheader does not work Description: http://bugs.php.net/bug.php?id=32311 mb_encode_mimeheader is did not operate by the influence that corrected this problem. Reproduce code: --- ? declare( encoding=EUC-JP ); var_dump( mb_encode_mimeheader( \è ) ); ? Expected result: string(34) =?ISO-2022-JP?B?GyRCST1CahsoQg==?= Actual result: -- string(2) hL -- Edit bug report at http://bugs.php.net/?id=33720edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33720r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33720r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33720r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33720r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33720r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33720r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33720r=needscript Try newer version: http://bugs.php.net/fix.php?id=33720r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33720r=support Expected behavior: http://bugs.php.net/fix.php?id=33720r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33720r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33720r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33720r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33720r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33720r=dst IIS Stability: http://bugs.php.net/fix.php?id=33720r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33720r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33720r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33720r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33720r=mysqlcfg
