Bug #51605 [Asn->Csd]: Mysqli - zombie links
Edit report at http://bugs.php.net/bug.php?id=51605&edit=1 ID: 51605 Updated by: and...@php.net Reported by: bastard dot internets at gmail dot com Summary: Mysqli - zombie links -Status: Assigned +Status: Closed Type: Bug Package: MySQLi related Operating System: vistax64 PHP Version: 5.3.2 Assigned To: mysql New Comment: Fix will appear in 5.3.3. Thanks for reporting this. Previous Comments: [2010-05-11 12:03:19] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=299239 Log: Fix for bug #51605 (Mysqli zombie links) [2010-04-24 04:40:58] bastard dot internets at gmail dot com Found a temporary solution - actually use real persistent connections: append "p:" to the hostname on mysqli::__connect(), set "mysqli.allow_persistent = On", set "mysqli.max_persistent = 1", and use all default mysql connection timeout settings. This correctly reuses the single active persistent link and established tcp socket connection for all page loads for as long as the connection timeout settings allow. Either that or revert to using the regular mysql extension. This doesn't take care of the growing number of active, permanent, non-persistent links spawned by any regular mysqli connection though. [2010-04-24 00:40:16] bastard dot internets at gmail dot com No Windows snapshots are currently available on http://windows.php.net/snapshots/ or http://windows.php.net/downloads/snaps/. Should I instead downgrade to PHP 5.2.13 release? [2010-04-23 22:14:36] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-04-22 02:53:02] bastard dot internets at gmail dot com Just to clarify - this is a closed server and db dev environment, and I'm the only one running the above script or connecting to the Mysql server. The 'too many links' PHP error would be expected if multiple users were hitting the page at the exact same time. But not expected if it's just me hitting refresh every once in a while. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51605 -- Edit this bug report at http://bugs.php.net/bug.php?id=51605&edit=1
Bug #51631 [Opn->Fbk]: MySQLi query result depend on browser
Edit report at http://bugs.php.net/bug.php?id=51631&edit=1 ID: 51631 Updated by: and...@php.net Reported by: evgpanchenko at gmail dot com Summary: MySQLi query result depend on browser -Status: Open +Status: Feedback Type: Bug Package: MySQLi related Operating System: Windows/Linux PHP Version: 5.3.2 New Comment: Please check what the source of the page you are receiving. Is it the same? If yes, then the browser is the problem. Previous Comments: [2010-04-22 11:50:22] evgpanchenko at gmail dot com Description: I have in MySQL Table with columns price DECIMAL(6,2), issm tinyint, cnt int When I run request SELECT IF(issm=1, ROUND(price/cnt, 6), price) AS price, issm with mysqli i get 12,00 1 12,00 0 in Opera and Chrome but i get 12,00 1 12,00 0 in mozilla and IE -- Edit this bug report at http://bugs.php.net/bug.php?id=51631&edit=1
Bug #51347 [Asn->Fbk]: mysqli_close / connection memory leak
Edit report at http://bugs.php.net/bug.php?id=51347&edit=1 ID: 51347 Updated by: and...@php.net Reported by: mat999 at gmail dot com Summary: mysqli_close / connection memory leak -Status: Assigned +Status: Feedback Type: Bug Package: MySQLi related Operating System: Debian Lenny / Linux PHP Version: 5.3.2 Assigned To: mysql New Comment: Yes, 5.3.2 has it, the fix I committed is in 5.3.3-dev, the future 5.3.3. I asked that you try it, if possible. Sources are available at http://snaps.php.net Previous Comments: [2010-04-25 07:08:57] mat999 at gmail dot com Ok tested it on php 5.3.2, sorry had issues getting php to build on my server (some hacks to get other stuff compiled have screwed with libs) Memory consumption after 0 iterations is 637088 Memory consumption after 1000 iterations is 829464 Memory consumption after 2000 iterations is 1021680 Memory consumption after 3000 iterations is 1222080 Memory consumption after 4000 iterations is 1406088 Memory consumption after 5000 iterations is 1622856 Memory consumption after 6000 iterations is 1806856 Memory consumption after 7000 iterations is 1990864 Memory consumption after 8000 iterations is 2174872 Memory consumption after 9000 iterations is 2424448 Memory consumption after 1 iterations is 2608448 Memory consumption after 11000 iterations is 2792464 Memory consumption after 12000 iterations is 2976472 Memory consumption after 13000 iterations is 3160480 Memory consumption after 14000 iterations is 3344480 Memory consumption after 15000 iterations is 3528496 Memory consumption after 16000 iterations is 3712504 Memory consumption after 17000 iterations is 4027576 Memory consumption after 18000 iterations is 4211640 Memory consumption after 19000 iterations is 4395640 Memory consumption after 2 iterations is 4579648 Memory consumption after 21000 iterations is 4763656 Memory consumption after 22000 iterations is 4947656 Memory consumption after 23000 iterations is 5131672 Memory consumption after 24000 iterations is 5315680 Memory consumption after 25000 iterations is 5499688 Memory consumption after 26000 iterations is 5683688 Memory consumption after 27000 iterations is 5867704 Memory consumption after 28000 iterations is 6051712 Memory consumption after 29000 iterations is 6235712 Memory consumption after 3 iterations is 6419720 Memory consumption after 31000 iterations is 6603736 Memory consumption after 32000 iterations is 6787736 Memory consumption after 33000 iterations is 7233888 Memory consumption after 34000 iterations is 7417896 Memory consumption after 35000 iterations is 7601912 Memory consumption after 36000 iterations is 7785912 Memory consumption after 37000 iterations is 7969920 Memory consumption after 38000 iterations is 8153928 Memory consumption after 39000 iterations is 8337928 Memory consumption after 4 iterations is 8521944 Memory consumption after 41000 iterations is 8705952 Memory consumption after 42000 iterations is 8889952 Memory consumption after 43000 iterations is 9073960 Memory consumption after 44000 iterations is 9257976 Memory consumption after 45000 iterations is 9441984 Memory consumption after 46000 iterations is 9625984 Memory consumption after 47000 iterations is 9809992 Memory consumption after 48000 iterations is 9994008 Memory consumption after 49000 iterations is 10178008 Memory consumption after 5 iterations is 10362016 Memory consumption after 51000 iterations is 10546024 Memory consumption after 52000 iterations is 10730024 Memory consumption after 53000 iterations is 10914040 Memory consumption after 54000 iterations is 11098048 Memory consumption after 55000 iterations is 11282056 Memory consumption after 56000 iterations is 11466056 Memory consumption after 57000 iterations is 11650072 Memory consumption after 58000 iterations is 11834080 Memory consumption after 59000 iterations is 12018080 Memory consumption after 6 iterations is 12202088 Memory consumption after 61000 iterations is 12386104 Memory consumption after 62000 iterations is 12570104 Memory consumption after 63000 iterations is 12754112 Memory consumption after 64000 iterations is 12938120 Memory consumption after 65000 iterations is 13122136 Memory consumption after 66000 iterations is 13830424 Memory consumption after 67000 iterations is 14014432 Memory consumption after 68000 iterations is 14198440 Memory consumption after 69000 iterations is 14382440 Memory consumption after 7 iterations is 14566456 Memory consumption after 71000 iterations is 14750464 Memory consumption after 72000 iterations is 14934472 Memory consumption after 73000 iterations is 15118472 Memory consumption after 74000 iterations is 15302488 Memory consumption after 75000 iterations is 15486496 M
[PHP-BUG] Bug #51791 [NEW]: constant() failed to check undefined constant and php interpreter stoped
From:
Operating system: Windows, Linux
PHP version: 5.3.2
Package: Reproducible crash
Bug Type: Bug
Bug description:constant() failed to check undefined constant and php
interpreter stoped
Description:
constant() failed to check undefined constant and php interpreter stoped,
but constant() should return NULL and php interpreter should continue to
work.
Test script:
---
class A
{
const B = 1;
}
var_dump(constant('A::B1'));
echo 5;
Expected result:
Warning: constant(): Couldn't find constant A::B1
NULL
5
Actual result:
--
>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
>php -r "class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;"
>php -r "class A { const B = 1;} var_dump(constant('A::B1')); echo 5;"
Fatal error: Undefined class constant 'A::B1' in Command line code on line
1
Call Stack:
0.0003 317608 1. {main}() Command line code:0
0.0003 317688 2. constant() Command line code:1
--
Edit bug report at http://bugs.php.net/bug.php?id=51791&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51791&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51791&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51791&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51791&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51791&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51791&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51791&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51791&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51791&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51791&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51791&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51791&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51791&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51791&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51791&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51791&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51791&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51791&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51791&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51791&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51791&r=mysqlcfg
Bug #48763 [Com]: ZipArchive produces corrupt OpenOffice.org files
Edit report at http://bugs.php.net/bug.php?id=48763&edit=1 ID: 48763 Comment by: l dot kneschke at metaways dot de Reported by: dani dot church at gmail dot com Summary: ZipArchive produces corrupt OpenOffice.org files Status: Feedback Type: Bug Package: Zip Related Operating System: CentOS 5 PHP Version: 5.2CVS-2009-07-01 (snap) Assigned To: pajoye New Comment: I just want to let you know that I can confirm that creating .ods files is working under windows. First it was not working for us under windows too. The main problem is, that .ods expects the internal name of the file(the second parameter of addFile) must have unix filesystem separators. When using windows filesystem separators the .ods zip archive is broken, even though extracting the archive is working. I'll also attach working example. Lars Previous Comments: [2010-04-28 16:43:12] paj...@php.net Can you try using 5.3.2 or 5.2.13 please? [2010-02-01 21:12:56] headofsteam at gmx dot com pajoye at php.net thanks for reopening. Don't suppose there is a way to transfer in my comment from #50893 ? Anyway, I have read through this report again and there may be a difference other than the OS and version. This report seems to be highlighting a problem in ZipArchive::AddFromString() I have been using the IMO more useful ZipArchive::AddFile() could that be significant. [2010-02-01 20:19:27] paj...@php.net reopen and assign to me. [2009-11-05 12:13:24] paj...@php.net Fixed in latest releases too. [2009-11-05 12:12:26] paj...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48763 -- Edit this bug report at http://bugs.php.net/bug.php?id=48763&edit=1
Bug #48763 [Com]: ZipArchive produces corrupt OpenOffice.org files
Edit report at http://bugs.php.net/bug.php?id=48763&edit=1 ID: 48763 Comment by: l dot kneschke at metaways dot de Reported by: dani dot church at gmail dot com Summary: ZipArchive produces corrupt OpenOffice.org files Status: Feedback Type: Bug Package: Zip Related Operating System: CentOS 5 PHP Version: 5.2CVS-2009-07-01 (snap) Assigned To: pajoye New Comment: Hm. I can't attach the working example. I'll place it on http://lars.kneschke.de/downloads/testODS.tar.bz2 Lars Previous Comments: [2010-05-11 12:26:00] l dot kneschke at metaways dot de I just want to let you know that I can confirm that creating .ods files is working under windows. First it was not working for us under windows too. The main problem is, that .ods expects the internal name of the file(the second parameter of addFile) must have unix filesystem separators. When using windows filesystem separators the .ods zip archive is broken, even though extracting the archive is working. I'll also attach working example. Lars [2010-04-28 16:43:12] paj...@php.net Can you try using 5.3.2 or 5.2.13 please? [2010-02-01 21:12:56] headofsteam at gmx dot com pajoye at php.net thanks for reopening. Don't suppose there is a way to transfer in my comment from #50893 ? Anyway, I have read through this report again and there may be a difference other than the OS and version. This report seems to be highlighting a problem in ZipArchive::AddFromString() I have been using the IMO more useful ZipArchive::AddFile() could that be significant. [2010-02-01 20:19:27] paj...@php.net reopen and assign to me. [2009-11-05 12:13:24] paj...@php.net Fixed in latest releases too. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48763 -- Edit this bug report at http://bugs.php.net/bug.php?id=48763&edit=1
Bug #48763 [Fbk]: ZipArchive produces corrupt OpenOffice.org files
Edit report at http://bugs.php.net/bug.php?id=48763&edit=1 ID: 48763 Updated by: paj...@php.net Reported by: dani dot church at gmail dot com Summary: ZipArchive produces corrupt OpenOffice.org files Status: Feedback Type: Bug Package: Zip Related Operating System: CentOS 5 PHP Version: 5.2CVS-2009-07-01 (snap) Assigned To: pajoye New Comment: Ok, it makes sense now. It is a good thing that you spotted this limitation in the ODS loader. We should add a note to the documentation. However please keep in mind that zip entry names are pure strings. They are not supposed to be path as we can see them. Even the notion of directory (filesystem directories) is not a known entity for zip archives. Danke :) Previous Comments: [2010-05-11 12:35:13] l dot kneschke at metaways dot de Hm. I can't attach the working example. I'll place it on http://lars.kneschke.de/downloads/testODS.tar.bz2 Lars [2010-05-11 12:26:00] l dot kneschke at metaways dot de I just want to let you know that I can confirm that creating .ods files is working under windows. First it was not working for us under windows too. The main problem is, that .ods expects the internal name of the file(the second parameter of addFile) must have unix filesystem separators. When using windows filesystem separators the .ods zip archive is broken, even though extracting the archive is working. I'll also attach working example. Lars [2010-04-28 16:43:12] paj...@php.net Can you try using 5.3.2 or 5.2.13 please? [2010-02-01 21:12:56] headofsteam at gmx dot com pajoye at php.net thanks for reopening. Don't suppose there is a way to transfer in my comment from #50893 ? Anyway, I have read through this report again and there may be a difference other than the OS and version. This report seems to be highlighting a problem in ZipArchive::AddFromString() I have been using the IMO more useful ZipArchive::AddFile() could that be significant. [2010-02-01 20:19:27] paj...@php.net reopen and assign to me. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48763 -- Edit this bug report at http://bugs.php.net/bug.php?id=48763&edit=1
Bug #48763 [Fbk->Tbd]: ZipArchive produces corrupt OpenOffice.org files
Edit report at http://bugs.php.net/bug.php?id=48763&edit=1 ID: 48763 Updated by: paj...@php.net Reported by: dani dot church at gmail dot com Summary: ZipArchive produces corrupt OpenOffice.org files -Status: Feedback +Status: To be documented Type: Bug Package: Zip Related Operating System: CentOS 5 PHP Version: 5.2CVS-2009-07-01 (snap) -Assigned To: pajoye +Assigned To: New Comment: Ok, it makes sense now. It is a good thing that you spotted this limitation in the ODS loader. We should add a note to the documentation. However please keep in mind that zip entry names are pure strings. They are not supposed to be path as we can see them. Even the notion of directory (filesystem directories) is not a known entity for zip archives. Danke :) Previous Comments: [2010-05-11 12:41:53] paj...@php.net Ok, it makes sense now. It is a good thing that you spotted this limitation in the ODS loader. We should add a note to the documentation. However please keep in mind that zip entry names are pure strings. They are not supposed to be path as we can see them. Even the notion of directory (filesystem directories) is not a known entity for zip archives. Danke :) [2010-05-11 12:35:13] l dot kneschke at metaways dot de Hm. I can't attach the working example. I'll place it on http://lars.kneschke.de/downloads/testODS.tar.bz2 Lars [2010-05-11 12:26:00] l dot kneschke at metaways dot de I just want to let you know that I can confirm that creating .ods files is working under windows. First it was not working for us under windows too. The main problem is, that .ods expects the internal name of the file(the second parameter of addFile) must have unix filesystem separators. When using windows filesystem separators the .ods zip archive is broken, even though extracting the archive is working. I'll also attach working example. Lars [2010-04-28 16:43:12] paj...@php.net Can you try using 5.3.2 or 5.2.13 please? [2010-02-01 21:12:56] headofsteam at gmx dot com pajoye at php.net thanks for reopening. Don't suppose there is a way to transfer in my comment from #50893 ? Anyway, I have read through this report again and there may be a difference other than the OS and version. This report seems to be highlighting a problem in ZipArchive::AddFromString() I have been using the IMO more useful ZipArchive::AddFile() could that be significant. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48763 -- Edit this bug report at http://bugs.php.net/bug.php?id=48763&edit=1
Req #51147 [Opn->Fbk]: mysql_connect can't resolve hostname within apache module
Edit report at http://bugs.php.net/bug.php?id=51147&edit=1 ID: 51147 Updated by: and...@php.net Reported by: kugel at rci dot rutgers dot edu Summary: mysql_connect can't resolve hostname within apache module -Status: Open +Status: Feedback Type:Feature/Change Request Package: MySQL related PHP Version: 5.2.12 New Comment: Operating system? Previous Comments: [2010-02-25 18:25:20] kugel at rci dot rutgers dot edu Description: When this is run from the command line: "php mytest.php" on the local machine, it connects successfully to the remote database. When it's run as a webpage, it dies with the mysql_error message of "Unknown MySQL server host 'mysql.vobj.org' (2)" Command line access "mysql -h mysql.vobj.org ..." works fine. If I substitute the IP address for the hostname, the webpage connects. NOTE: vobj.org is hosted by dreamhost, and while mysql.vobj.org maps to 67.205.28.132, 67.205.28.132 maps to thadison.masevo.dreamhost.com. Maybe there's some IP security check that causes failure without generating a useful error message. Fedora 11 host, Apache/2.2.13 (Fedora) Reproduce code: --- \n"; mysql_close($link); ?> Expected result: Code should say "successful connection\n" Actual result: -- Could not connect: MySQL server host 'mysql.vobj.org' (2) -- Edit this bug report at http://bugs.php.net/bug.php?id=51147&edit=1
Req #51147 [Fbk]: mysql_connect can't resolve hostname within apache module
Edit report at http://bugs.php.net/bug.php?id=51147&edit=1 ID: 51147 Updated by: paj...@php.net Reported by: kugel at rci dot rutgers dot edu Summary: mysql_connect can't resolve hostname within apache module Status: Feedback Type:Feature/Change Request Package: MySQL related PHP Version: 5.2.12 Assigned To: mysql New Comment: Fedora 11 host, Apache/2.2.13 (Fedora) (from the report) Previous Comments: [2010-05-11 12:46:50] and...@php.net Operating system? [2010-02-25 18:25:20] kugel at rci dot rutgers dot edu Description: When this is run from the command line: "php mytest.php" on the local machine, it connects successfully to the remote database. When it's run as a webpage, it dies with the mysql_error message of "Unknown MySQL server host 'mysql.vobj.org' (2)" Command line access "mysql -h mysql.vobj.org ..." works fine. If I substitute the IP address for the hostname, the webpage connects. NOTE: vobj.org is hosted by dreamhost, and while mysql.vobj.org maps to 67.205.28.132, 67.205.28.132 maps to thadison.masevo.dreamhost.com. Maybe there's some IP security check that causes failure without generating a useful error message. Fedora 11 host, Apache/2.2.13 (Fedora) Reproduce code: --- \n"; mysql_close($link); ?> Expected result: Code should say "successful connection\n" Actual result: -- Could not connect: MySQL server host 'mysql.vobj.org' (2) -- Edit this bug report at http://bugs.php.net/bug.php?id=51147&edit=1
Bug #47982 [Asn->Opn]: PDO_mysql: Storing image binary data
Edit report at http://bugs.php.net/bug.php?id=47982&edit=1
ID: 47982
Updated by: u...@php.net
Reported by: markac at home dot pl
Summary: PDO_mysql: Storing image binary data
-Status: Assigned
+Status: Open
Type: Bug
Package: MySQL related
Operating System: WinXP
PHP Version: 5.2CVS-2009-04-16 (snap)
-Assigned To: mysql
+Assigned To:
New Comment:
Not a MySQL specific issue. PDO general/PDO specification issue.
Previous Comments:
[2009-08-25 14:04:35] u...@php.net
I don't call this a bug.
PDO::PARAM_LOB "can be either textual or binary in nature":
"At some point in your application, you might find that you need to
store "large" data in your database. Large typically means "around 4kb
or more", although some databases can happily handle up to 32kb before
data becomes "large". Large objects can be either textual or binary in
nature. PDO allows you to work with this large data type by using the
PDO::PARAM_LOB type code in your PDOStatement::bindParam() or
PDOStatement::bindColumn() calls. PDO::PARAM_LOB tells PDO to map the
data as a stream, so that you can manipulate it using the PHP Streams
API.", http://www.php.net/manual/en/pdo.lobs.php
PDO_MySQL threats PDO::PARAM_LOB like textual data. Textual data needs
to be escaped. This is what also happens if you use the PDO Prepared
Statmeent emulation, which has been a default for a long time. When
using the emulation, the column will be seen as textual data and be
escaped.
This, however, is not a MySQL specific problem. MySQL is affected
because it supports charsets and stuff. But every other PDO driver
supporting charsets is affected as well.
A proper fix would be to introduce PDO::PARAM_BLOB for use with binary
data. PDO::PARAM_BLOB should go into the PDO core. As changes to the
core can impact all drivers, a volunteer is needed to check and/or
update all drivers to get this PDO flaw fixed.
Ulf
[2009-04-22 10:51:40] johan...@php.net
Thanks. Got it now reproduced using 5.2 as well as 5.3 (with both
libmysql and mysqlnd)
[2009-04-21 18:48:05] markac at home dot pl
Only dependant on the SET NAMES.
[2009-04-21 15:10:53] johan...@php.net
I'm not sure I correctly understand your both last messages. Is the
problem only dependant on the SET NAMES call or also on the server
version?
Thanks for clarification.
[2009-04-16 13:33:16] markac at home dot pl
Sorry once again. Works when
$pdo->exec('SET CHARACTER SET utf8');
is commented.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47982
--
Edit this bug report at http://bugs.php.net/bug.php?id=47982&edit=1
Bug #46508 [Asn->Opn]: [PATCH]: getColumnMeta returns 'LONG','VAR_STRING','BLOB' as php native_type
Edit report at http://bugs.php.net/bug.php?id=46508&edit=1 ID: 46508 Updated by: u...@php.net Reported by: marques at displague dot com Summary: [PATCH]: getColumnMeta returns 'LONG','VAR_STRING','BLOB' as php native_type -Status: Assigned +Status: Open Type: Bug Package: PDO related Operating System: * PHP Version: 5.2.9 -Assigned To: mysql +Assigned To: New Comment: Whatever the docs say, what counts is "EXPERIMENTAL" = "TENTATIVE" = "UNDEFINED". It is irrelevant how meaningful and sensible your suggestion is. If you want any changes to PDO, please write an RFC/discuss on internal/do whatever the current procedure is to get the "EXPERIMENTAL" removed. Specification via bug reports does not make much sense to me. You fix one and break another causing a bug report stating just the opposite and, for example, claiming you break backwards compatibility. The underlying issue is the lack of a clear definition. The issue is the "EXPERIMENTAL". I do understand how annoying the answer is. But please respect that "specification via bug reports" is not a good approach and sometimes it is better to go a step back and do it right: fix PDO as such. Whoever wants, may play the patch-and-work-without-specs game. But I won't do it. Its an endless game leading nowhere: leaving bug open, unassigning mysql (at least as long as there is no clear specs). Previous Comments: [2009-06-29 10:18:50] marques at displague dot com I stated in the bug report that the return values do not match up with the documentation. The docs state (pretty clearly): http://php.net/manual/en/pdostatement.getcolumnmeta.php: native_type The PHP native type used to represent the column value. driver:decl_typeThe SQL type used to represent the column value in the database. If the column in the result set is the result of a function, this value is not returned by PDOStatement::getColumnMeta(). pdo_typeThe type of this column as represented by the PDO::PARAM_* constants. The problems are that (per the docs) native_type is missed for some types (TINYINT) and that the native_type values currently returned should be in driver:decl_type, and PHP native types should be returned for native_type instead. [2009-06-29 09:42:27] uwendel at mysql dot com Why would I bother about a function that has no specification? Without a specification there is no definition of how things should go and there is no bug - by definition... "Warning This function is EXPERIMENTAL. The behaviour of this function, its name, and surrounding documentation may change without notice in a future release of PHP. This function should be used at your own risk. ", http://de.php.net/manual/en/pdostatement.getcolumnmeta.php There needs to be a proper PDO spec before one can decide about any bug report. IMHO the bug report should be closed as bogus. [2009-04-10 14:01:57] php at displague dot com This should probably be the topic of another bug, but TINYINT doesn't return a native_type (I'm guessing because TINY is used everywhere, but not TINYINT - maybe another constant is needed). mysql://u...@host/db> show columns from table like 'disable' \G; *** 1. row *** Field: disable Type: tinyint(4) Null: NO Key: Default: 0 Extra: 1 row in set (0.00 sec) getColumnMeta (php 5.2.9) returns: Array ( [flags] => Array ( [0] => not_null ) [table] => promo_item [name] => disable [len] => 4 [precision] => 0 [pdo_type] => 2 ) native_type is missing. Is there any chance this correction will make it into 5.2.x? [2008-11-07 16:24:52] fel...@php.net Hi Marques, good observation! I've updated the patch. ;) Thanks. [2008-11-07 16:02:59] marques at displague dot com The values that are currently being reported may belong in the getmetacolumn array member 'driver:decl_type' (per the getColumnMeta documentation example). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=46508 -- Edit this bug report at http://bugs.php.net/bug.php?id=46508&edit=1
Bug #51079 [Com]: fsockopen will not work on 'localhost'
Edit report at http://bugs.php.net/bug.php?id=51079&edit=1
ID: 51079
Comment by: anders at ingemann dot de
Reported by: tony at marston-home dot demon dot co dot uk
Summary: fsockopen will not work on 'localhost'
Status: Assigned
Type: Bug
Package: Sockets related
Operating System: win32 only - Windows XP
PHP Version: 5.2.12
Assigned To: pajoye
New Comment:
I can confirm this on Vista x86 with the precompiled 5.3.2 VC6 ts
Previous Comments:
[2010-04-28 00:03:32] jbphp at jlb dot nu
We recently upgraded to PHP 5.3.2 and can replicate this problem under
Windows 7 x64.
Luckily the workaround of using '127.0.0.1' in the fsockopen address
instead of 'localhost' is relatively easy but it broke a large volume of
our existing code. Very annoying.
Please fix this asap.
[2010-03-13 20:26:19] dontwantanyspam at mailinator dot com
Forgot to mention my operating system. Windows 7 x64.
[2010-03-13 20:22:24] dontwantanyspam at mailinator dot com
I can also confirm that this problem isn't there in PHP 5.3.0. Its there
since
5.3.1.
Unlike PHP 5.3.0, a 64 bit version of PHP 5.3.1 wasn't available at
http://windows.php.net/qa/, so I tried compiling it myself. After
compiling I
noticed that a script that uses
file_get_contents("http://localhost/...";)
wouldn't work until I change the "localhost" to "127.0.0.1". I didn't
care about
it much at that time since it seemed like a small problem. But then I
noticed
that none of the scripts that used mysql were working. I even tried to
log in to
phpMyAdmin and even that didn't work (same problem described by
thijsputman). So
I thought that it was probably a bug with the 64 bit binary and
continued using
PHP 5.3.0.
But after PHP 5.3.2 was released, I tried compiling it also and noticed
that the
problem was still there. Thinking that it may be related to mysqlnd
since the
version used by PHP 5.3.0 is 5.0.5-dev and the one used by PHP 5.3.2 is
5.0.7-
dev, I tried compiling the mysql, mysqli and pdo mysql extensions with
libmysql.
I has success with the mysql extension only. The mysqli and pdo mysql
extension
failed to compile with libmysql (there were a lot of build errors).
Anyway, I
tried the mysql extension compiled with libmysql and noticed that it was
working
fine! But I needed the mysqli extension to work also and since it failed
to
compile with libmysql, I messed around some more and finally realized
that it
was the same problem as with the file_get_contents. So I tried changing
all the
"localhost" references to "127.0.0.1" and it worked!
Anyway, for whatever reason the mysql extension compiled with libmysql
works
fine with "localhost" but the one compiled with mysqlnd doesn't. So, I
hope this
helps you to find and squish the bug thats causing this. :D
[2010-03-10 12:31:15] thijsputman at gmail dot com
Fair enough :)
The reproduce code provided fails to connect to "localhost" with
fsockopen() in PHP 5.3.2. When using PHP 5.3.0 fsockopen() connects to
"localhost" without problems.
[2010-03-10 12:03:59] paj...@php.net
It does not depend on PHP only but libmysql or mysql server. Please keep
posting about the socket issue only here as the myslq&IPv6 questions
have been covered numerous times in other reports. The one report per
issue rule is also a good way to do not get distracted, thanks for your
understanding :)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51079
--
Edit this bug report at http://bugs.php.net/bug.php?id=51079&edit=1
Bug #51372 [Com]: php5-ffmpeg extension causes php to coredump
Edit report at http://bugs.php.net/bug.php?id=51372&edit=1 ID: 51372 Comment by: endzed at gmail dot com Reported by: daynejordan at gmail dot com Summary: php5-ffmpeg extension causes php to coredump Status: Bogus Type: Bug Package: Unknown/Other Function Operating System: FreeBSD-7.3 PHP Version: 5.2.13 New Comment: I experience the same issue with PHP 5.3.2 on 7.3-RELEASE/amd64 My backtrace looks like very different (very long, sorry...), but this is my first backtrace so... ad1# php -m [PHP Modules] Core date ereg ffmpeg libxml pcre Reflection SPL standard [Zend Modules] Segmentation fault (core dumped) ad1# ffmpeg -version FFmpeg version 0.5.1, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --prefix=/usr/local --mandir=/usr/local/man --enable-shared -- enable- gpl --enable-swscale --enable-postproc --enable-avfilter --enable-avfilter-lavf -- enable-pthreads --enable-memalign-hack --cc=cc --extra-cflags=-msse - I/usr/local/include/vorbis -I/usr/local/include --extra-ldflags=-L/usr/local/lib -- extra-libs=-pthread --disable-debug --disable-libamr-nb --disable-libamr-wb -- disable- libdirac --disable-libfaac --enable-libfaad --enable-libfaadbin --disable-libgsm -- disable-vhook --enable-ipv6 --disable-libmp3lame --disable-libopenjpeg --enable- libschroedinger --disable-ffplay --disable-libspeex --enable-libtheora --enable- libvorbis --disable-x11grab --enable-libx264 --disable-libxvid libavutil 49.15. 0 / 49.15. 0 libavcodec52.20. 1 / 52.20. 1 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on May 11 2010 14:36:44, gcc: 4.2.1 20070719 [FreeBSD] FFmpeg 0.5.1 libavutil 49.15. 0 / 49.15. 0 libavcodec52.20. 1 / 52.20. 1 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 ad1# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008023bd820 in ?? () (gdb) bt #0 0x0008023bd820 in ?? () #1 0x000800db47d5 in xmlFreeMutex () from /usr/local/lib/libxml2.so.5 #2 0x000800db4215 in xmlCleanupGlobals () from /usr/local/lib/libxml2.so.5 #3 0x000800d4cd3a in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #4 0x00444d18 in php_libxml_shutdown () #5 0x00444d49 in zm_shutdown_libxml () #6 0x005333cf in module_destructor () #7 0x0053a444 in zend_hash_apply_deleter () #8 0x0053a6b8 in zend_hash_graceful_reverse_destroy () #9 0x0052eaf8 in zend_shutdown () #10 0x004dd03a in php_module_shutdown () #11 0x005b56b2 in main () #12 0x00415e6e in _start () #13 0x000800799000 in ?? () #14 0x in ?? () #15 0x0002 in ?? () #16 0x7fffedb0 in ?? () #17 0x7fffedb4 in ?? () #18 0x in ?? () #19 0x7fffedb7 in ?? () #20 0x7fffedc1 in ?? () #21 0x7fffedce in ?? () #22 0x7fffedd9 in ?? () #23 0x7fffeded in ?? () #24 0x7fffee44 in ?? () #25 0x7fffee55 in ?? () #
Bug #51601 [Asn->Fbk]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1
ID: 51601
Updated by: johan...@php.net
Reported by: pcarter at jhu dot edu
Summary: Segmentation fault when using the 2-argument form of
mysql_fetch_array
-Status: Assigned
+Status: Feedback
Type: Bug
Package: MySQL related
Operating System: FreeBSD 6.2-RELEASE
PHP Version: 5.3.2
Assigned To: mysql
New Comment:
Could you please provide the configure line. Please also try using plain
PHP, not ports which applies random patches we don't control.
Please also make sure that you're loading the correct mysql.so in case
you're building the mysql extension shared.
Previous Comments:
[2010-04-29 14:47:07] elmex at voll dot in
i have problems with mysql_fetch_array($resurce, MYSQL_ASSOC) returning
no result set, if i replace it with mysql_fetch_assoc($resurce) it works
fine
this happens since update to last 5.3 php with freebsd ports
[2010-04-22 03:14:55] pcarter at jhu dot edu
The problem persists with php5.3-201004220030. The backtrace is
identical save instruction addresses.
[2010-04-22 02:19:19] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-19 17:04:44] pcarter at jhu dot edu
I missed on the package dropdown when submitting the bug. This belongs
with the MySQL package, not the MSSQL package.
[2010-04-19 17:03:06] pcarter at jhu dot edu
Description:
When using the two-argument form of mysql_fetch_array PHP experiences a
segmentation fault in zend_fetch_resource, attempting to dereference a
null pointer. (specifically *passed_id is ((* zval)(0x0)) when
performing the IS_RESOURCE check). This happens regardless of which of
the three MYSQL_{BOTH|ASSOC|NUM} constants are used as the second
argument (the given script uses MYSQL_BOTH). This problem does not
occur when using the single argument form of mysql_fetch_array, and it
does not occur when using the mysql_fetch_assoc() or mysql_fetch_row()
functions.
Test environment is FreeSBD 6.2-RELEASE on amd64, with the MySQL 5.0
client library installed.
Test script:
---
Expected result:
The script should print an array (numerically and associatively indexed)
of the tables in the database "test".
Actual result:
--
Segmentation fault as noted above. Backtrace:
Backtrace:
#0 0x00638ed3 in zend_fetch_resource (passed_id=0x7fffce30,
default_id=-1, resource_type_name=0x72fa51 "MySQL result",
found_resource_type=0x0, num_resource_types=1)
at /usr/local/src/php-5.3.2/Zend/zend_list.c:127
#1 0x004d76a6 in php_mysql_fetch_hash (ht=2,
return_value=0x9240a0, return_value_ptr=0x638ddf, this_ptr=0x0,
return_value_used=1, result_type=3, expected_args=2, into_object=0)
at /usr/local/src/php-5.3.2/ext/mysql/php_mysql.c:1944
#2 0x004d7c2b in zif_mysql_fetch_array (ht=-12752,
return_value=0x, return_value_ptr=0x638ddf, this_ptr=0x0,
return_value_used=1) at
/usr/local/src/php-5.3.2/ext/mysql/php_mysql.c:2105
#3 0x0064e192 in zend_do_fcall_common_helper_SPEC
(execute_data=0xb45040) at zend_vm_execute.h:313
#4 0x0064d5b9 in execute (op_array=0x9248c8) at
zend_vm_execute.h:104
#5 0x0062b765 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-5.3.2/Zend/zend.c:1194
#6 0x005d955b in php_execute_script
(primary_file=0x7fffeb00) at
/usr/local/src/php-5.3.2/main/main.c:2260
#7 0x006b2bca in main (argc=2, argv=0x7fffec00) at
/usr/local/src/php-5.3.2/sapi/cli/php_cli.c:1192
--
Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Bug #1 [Asn->Csd]: Apache 1.3b3 + mod_php3 is slow
Edit report at http://bugs.php.net/bug.php?id=1&edit=1 ID: 1 Updated by: j...@php.net Reported by: rasmus at lerdorf dot on dot ca Summary: Apache 1.3b3 + mod_php3 is slow -Status: Assigned +Status: Closed Type: Bug Package: Performance problem Operating System: Solaris 2.5.1 PHP Version: 3.0b3 Assigned To: felipe Previous Comments: [2010-03-17 17:00:12] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revision&revision=296329 Log: Improve Windows build system take #1 * Generate configure.bat * Use php_gtk_build as first priority build folder to prevent interfering with php-src builds * Write 2 blank lines before the error message in ERROR() to prevent error messages while detecting locations to look screwy * Proper detect MSVC versions, merged from php-src (Fixes #50888) [2010-03-09 18:16:37] j...@php.net The following patch has been added/updated: Patch Name: testing Revision: 1268154997 URL: http://bugs.php.net/patch-display.php?bug=1&patch=testing&revision=1268154997 [2010-03-09 18:16:16] fel...@php.net The following patch has been added/updated: Patch Name: testing Revision: 1268154976 URL: http://bugs.php.net/patch-display.php?bug=1&patch=testing&revision=1268154976 [2010-03-09 17:48:29] fel...@php.net The following patch has been added/updated: Patch Name: abcc Revision: 1268153309 URL: http://bugs.php.net/patch-display.php?bug=1&patch=abcc&revision=1268153309&display=1 [2010-03-09 17:47:29] fel...@php.net The following patch has been added/updated: Patch Name: abc Revision: 1268153249 URL: http://bugs.php.net/patch-display.php?bug=1&patch=abc&revision=1268153249&display=1 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=1 -- Edit this bug report at http://bugs.php.net/bug.php?id=1&edit=1
Bug #51372 [Com]: php5-ffmpeg extension causes php to coredump
Edit report at http://bugs.php.net/bug.php?id=51372&edit=1 ID: 51372 Comment by: endzed at gmail dot com Reported by: daynejordan at gmail dot com Summary: php5-ffmpeg extension causes php to coredump Status: Bogus Type: Bug Package: Unknown/Other Function Operating System: FreeBSD-7.3 PHP Version: 5.2.13 New Comment: Solved ! Still this annoying issue with libxml2, see here http://forums.freebsd.org/archive/index.php/t-8965.html No more segmentation fault if I remove theses lines from the "patch-configure" file of the libxml2 port and rebuild libxml2 (no need to rebuild php5* stuff btw) : @@ -20665,6 +20666,8 @@ fi fi ;; + *freebsd*) THREAD_LIBS="" + ;; esac if test "$WITH_THREADS" = "1" ; then THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT" I don't understand what is the internal difference be cause no knowledge of those threads stuffs, but could be a good thing for the libxml2 maintainer to check this and modify the patch-configure file accordingly. my 2cts, hope this help. Previous Comments: [2010-05-11 14:53:11] endzed at gmail dot com I experience the same issue with PHP 5.3.2 on 7.3-RELEASE/amd64 My backtrace looks like very different (very long, sorry...), but this is my first backtrace so... ad1# php -m [PHP Modules] Core date ereg ffmpeg libxml pcre Reflection SPL standard [Zend Modules] Segmentation fault (core dumped) ad1# ffmpeg -version FFmpeg version 0.5.1, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --prefix=/usr/local --mandir=/usr/local/man --enable-shared -- enable- gpl --enable-swscale --enable-postproc --enable-avfilter --enable-avfilter-lavf -- enable-pthreads --enable-memalign-hack --cc=cc --extra-cflags=-msse - I/usr/local/include/vorbis -I/usr/local/include --extra-ldflags=-L/usr/local/lib -- extra-libs=-pthread --disable-debug --disable-libamr-nb --disable-libamr-wb -- disable- libdirac --disable-libfaac --enable-libfaad --enable-libfaadbin --disable-libgsm -- disable-vhook --enable-ipv6 --disable-libmp3lame --disable-libopenjpeg --enable- libschroedinger --disable-ffplay --disable-libspeex --enable-libtheora --enable- libvorbis --disable-x11grab --enable-libx264 --disable-libxvid libavutil 49.15. 0 / 49.15. 0 libavcodec52.20. 1 / 52.20. 1 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on May 11 2010 14:36:44, gcc: 4.2.1 20070719 [FreeBSD] FFmpeg 0.5.1 libavutil 49.15. 0 / 49.15. 0 libavcodec52.20. 1 / 52.20. 1 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 ad1# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008023bd820 in ?? () (gdb) bt #0 0x0008023bd820 in ?? () #1 0x000800db47d5 in xmlFreeMutex () from /usr/local/lib/libxml2.so.5 #2 0x000800db4215 in xmlCleanupGlobals () from /usr/local/lib/libxml2.so.5 #3 0x000800d4cd3a in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #4 0x00444d18 in php_l
[PHP-BUG] Req #51793 [NEW]: Add alpha argument to imagecolorset
From: Operating system: linux PHP version: 5.3.2 Package: GD related Bug Type: Feature/Change Request Bug description:Add alpha argument to imagecolorset Description: Imagecolorset currently has no argument to set the alpha color component in an indexed color image. This capability would be very useful. (Especially when dealing with functions that use antialiasing but don't handle alpha transparency well). Change to: void imagecolorset ( resource $image, int $index, int $red, int $green, int $blue [, int $alpha ] ) -- Edit bug report at http://bugs.php.net/bug.php?id=51793&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51793&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51793&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51793&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51793&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51793&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51793&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51793&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51793&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51793&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51793&r=support Expected behavior: http://bugs.php.net/fix.php?id=51793&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51793&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51793&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51793&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51793&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51793&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51793&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51793&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51793&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51793&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51793&r=mysqlcfg
[PHP-BUG] Bug #51794 [NEW]: String keys in arrays are treated as 0, if not set
From: Operating system: OS X 10.6 PHP version: 5.3.2 Package: Arrays related Bug Type: Bug Bug description:String keys in arrays are treated as 0, if not set Description: I tried to access an array key by string value. But the variable I accessed was no array, but a string. As stated in the manual you can access single chars by numeric array keys, which makes perfect sense. But if I try to use a string it is treated as 0 (zero). Too much type jugglin'? Test script: --- Expected result: PHP NOTICE - $link['bar'] is not defined. Actual result: -- f -- Edit bug report at http://bugs.php.net/bug.php?id=51794&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51794&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51794&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51794&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51794&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51794&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51794&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51794&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51794&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51794&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51794&r=support Expected behavior: http://bugs.php.net/fix.php?id=51794&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51794&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51794&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51794&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51794&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51794&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51794&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51794&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51794&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51794&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51794&r=mysqlcfg
[PHP-BUG] Bug #51795 [NEW]: Loose comparison too loose
From:
Operating system: Ubuntu
PHP version: 5.2.13
Package: Strings related
Bug Type: Bug
Bug description:Loose comparison too loose
Description:
if ("0080" == "80e0") echo "Smoking crack!";
I created a double octet coded character set. I'm using 4 hex to represent
each character. I'm using a switch statement to get a token based on the
value. The string "80e0" is incorrectly setting off the case "0080"
statement.
The strict comparison of === works as expected, but the switch uses a loose
comparison.
Test script:
---
if ("0080" == "80e0") {
echo "Too loose";
} else {
echo "Just right";
}
Expected result:
Just right
Actual result:
--
Too loose
--
Edit bug report at http://bugs.php.net/bug.php?id=51795&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51795&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51795&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51795&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51795&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51795&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51795&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51795&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51795&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51795&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51795&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51795&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51795&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51795&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51795&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51795&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51795&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51795&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51795&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51795&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51795&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51795&r=mysqlcfg
Bug #49893 [Bgs->Asn]: Apache 2.2 Child crash while creating an instance of Zend_Mail_Storage_Pop3
Edit report at http://bugs.php.net/bug.php?id=49893&edit=1
ID: 49893
Updated by: dmi...@php.net
Reported by: greubel at nkey dot de
Summary: Apache 2.2 Child crash while creating an instance of
Zend_Mail_Storage_Pop3
-Status: Bogus
+Status: Assigned
Type: Bug
Package: Reproducible crash
-Operating System: Windows Vista
+Operating System: *
PHP Version: 5.3.0
-Assigned To:
+Assigned To: dmitry
New Comment:
The bug occurs when exception is caught in destructor during another
exception processing
Reproduce code:
---
getMessage() . "\n";
}
}
}
class B {
function __construct() {
$this->a = new A();
throw new Exception("1");
}
}
try {
$b = new B();
} catch(Exception $e) {
echo $e->getMessage() . "\n";;
}
?>
Expected result:
2
1
Actual result:
--
2
valgrind
==26823== Invalid read of size 4
==26823==at 0x856480A: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (zend.h:385)
==26823==by 0x84D7B98: execute (zend_vm_execute.h:104)
==26823==by 0x84ACA44: zend_execute_scripts (zend.c:1194)
==26823==by 0x844186E: php_execute_script (main.c:2260)
==26823==by 0x8572CDE: main (php_cli.c:1192)
==26823== Address 0x51f1428 is 8 bytes inside a block of size 20
free'd
==26823==at 0x4B8C90A: free (vg_replace_malloc.c:323)
==26823==by 0x848B079: _efree (zend_alloc.c:2348)
==26823==by 0x849C3E3: _zval_ptr_dtor (zend_execute_API.c:444)
==26823==by 0x84D8156: zend_leave_helper_SPEC
(zend_vm_execute.h:226)
==26823==by 0x84DA521: ZEND_HANDLE_EXCEPTION_SPEC_HANDLER
(zend_vm_execute.h:680)
==26823==by 0x84D7B98: execute (zend_vm_execute.h:104)
==26823==by 0x84ACA44: zend_execute_scripts (zend.c:1194)
==26823==by 0x844186E: php_execute_script (main.c:2260)
==26823==by 0x8572CDE: main (php_cli.c:1192)
Previous Comments:
[2009-10-20 20:57:38] paj...@php.net
not a bug > bogus.
[2009-10-20 20:13:15] greubel at nkey dot de
Not reproducable
[2009-10-20 20:11:41] greubel at nkey dot de
Please close. I'm not able to reproduce the problem with a small script.
I tried to strip down the code from ZF to provide the same functionality
but provoke the bug. This seems to be not possible on this
circumstances.
This code works well:
sock = fsockopen('pop.gmx.net', 110, $this->errno,
$this->error);
$r = fgets($this->sock);
echo "$r";
fputs($this->sock, "USER mike.greu...@gmx.de\r\n");
$r = fgets($this->sock);
echo "$r";
fputs($this->sock, "PASS \r\n");
$r = fgets($this->sock);
echo "$r";
fputs($this->sock, "QUIT\r\n");
$r = fgets($this->sock);
echo "$r";
}
public function close()
{
fclose($this->sock);
$this->sock = null;
}
}
$bar = new foo();
$bar->close();
?>
So please close.
[2009-10-20 19:53:24] paj...@php.net
We *still* need a way to reproduce your problem. that means a small
script as described already in one of my comments.
[2009-10-20 18:54:33] greubel at nkey dot de
The access violation has now moved to another place:
php5ts!gc_zobj_possible_root+57 038ffbc0 0273b270 038fe608
php5ts!gc_zval_possible_root+74 038ffbc0 0273b270
php5ts!ZEND_ASSIGN_SPEC_CV_VAR_HANDLER+69 0094fbc0 0273b270
0094fe3c
php5ts!execute+2fb 039310b0 0273b200
php5ts!zend_execute_scripts+f6 0008 0273b270
php5ts!php_execute_script+233 0094fe3c 0273b270 0004
php5apache2_2!php_handler+5d0 0275ead8 00a24208 0275ead8
libhttpd!ap_run_handler+21 0275ead8 0275ead8 0275ead8
libhttpd!ap_invoke_handler+ae 02847fc0 0094ff00
libhttpd!ap_die+29e 0275ead8 021b51c0
libhttpd!ap_get_request_note+1ccc 02847fc0 02847fc0 02847fc0
libhttpd!ap_run_process_connection+21 02847fc0 00974f20
0094ff48
libhttpd!ap_process_connection+33 02847fc0 021c81a8
libhttpd!ap_regkey_value_remove+c7c 02847fb8 a899cc42
msvcrt!_endthreadex+44 0094ff94 76bdd0e9 02746848
msvcrt!_endthreadex+ce 02746848 0094ffd4 775919bb
kernel32!BaseThreadInitThunk+e
Bug #51601 [Fbk->Opn]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1 ID: 51601 User updated by: pcarter at jhu dot edu Reported by: pcarter at jhu dot edu Summary: Segmentation fault when using the 2-argument form of mysql_fetch_array -Status: Feedback +Status: Open Type: Bug Package: MySQL related Operating System: FreeBSD 6.2-RELEASE PHP Version: 5.3.2 Assigned To: mysql New Comment: My test was run initially with PHP compiled from source pulled from php.net, and as noted the problem persisted with php5.3-201004220030, and ldd claims I'm linking against the correct libmysqlclient.so Configure line is: './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--program-prefix=' '--enable-session' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' '--enable-dom' '--enable-json' '--enable-simplexml' '--enable-soap' '--with-openssl' '--with-pgsql' '--with-mysql' '--enable-tokenizer' '--enable-xml' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--enable-cli' '--enable-zip' Previous Comments: [2010-05-11 15:25:37] johan...@php.net Could you please provide the configure line. Please also try using plain PHP, not ports which applies random patches we don't control. Please also make sure that you're loading the correct mysql.so in case you're building the mysql extension shared. [2010-04-29 14:47:07] elmex at voll dot in i have problems with mysql_fetch_array($resurce, MYSQL_ASSOC) returning no result set, if i replace it with mysql_fetch_assoc($resurce) it works fine this happens since update to last 5.3 php with freebsd ports [2010-04-22 03:14:55] pcarter at jhu dot edu The problem persists with php5.3-201004220030. The backtrace is identical save instruction addresses. [2010-04-22 02:19:19] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-04-19 17:04:44] pcarter at jhu dot edu I missed on the package dropdown when submitting the bug. This belongs with the MySQL package, not the MSSQL package. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51601 -- Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Req #28919 [Com]: foreach does not take list() as argument output
Edit report at http://bugs.php.net/bug.php?id=28919&edit=1
ID: 28919
Comment by: rc at opelgt dot org
Reported by: black at scene-si dot org
Summary: foreach does not take list() as argument output
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: any
PHP Version: Irrelevant
New Comment:
Why not using this code?
foreach ($table as $key=>$val) {
echo $key.":".$val[0].", ".$val[1]."\n";
}
Previous Comments:
[2004-06-25 19:48:45] poll...@php.net
This is expected behavior. list() is a left-hand language construct and
not currently intended to be used this way.
Reclassifying to Feature/Change Request.
[2004-06-25 13:20:05] black at scene-si dot org
Description:
Requesting additional functionality for foreach?
Reproduce code:
---
$table = array();
$table['username'] = array(1,"John doe");
$table['black'] = array(2,"Jane doe");
$table['yawn'] = array(3,"Undefined");
foreach ($table as $key=>list($id,$title)) {
echo $key.":".$id.", ".$title."\n";
}
foreach ($table as list($id,$title)) {
echo $id.", ".$title."\n";
}
Expected result:
username:1, John doe
black:2, Jane doe
yawn:3, Undefined
1, John doe
2, Jane doe
3, Undefined
Actual result:
--
Parse error
--
Edit this bug report at http://bugs.php.net/bug.php?id=28919&edit=1
[PHP-BUG] Bug #51796 [NEW]: Memory leak when executing SQL "EXEC" statements
From:
Operating system: Ubuntu 10.04 LTS
PHP version: 5.3.2
Package: PDO related
Bug Type: Bug
Bug description:Memory leak when executing SQL "EXEC" statements
Description:
On Linux, using PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) and FreeTDS
0.82-6build1 (it's a vanilla lucid install, fully up to date):
When executing stored procedures using the "EXEC" SQL statement, both
PDOStatement->execute as well as PDO::query seem to have a memory leak. We
found this while executing a stored procedure within a loop: memory usage
just kept increasing till the memory limit was reached. Unsetting/nullyfing
variables does not help.
The leak is not present (memory usage stays perfectly constant) when using
a "SELECT" SQL statement (which returns the exact same results as the
stored procedure).
I have a feeling PDO is maybe only clearing the memory when it deals with a
"SELECT" statement, and it misses the fact that data can also come back
through "EXEC" statements?
This bug might be slightly related to bug 50755.
Test script:
---
// $polyItemArray is populated with a list of 300 IDs (integers).
// We loop through the array, and execute a stored procedure during each
iteration:
foreach( $polyItemArray as $polyItemKey => $polyItem) {
echo date('H:i:s') . ' | Processing: ' . $polyItem['sgp_id'];
$dbh->query('EXEC proc_map_get_sgp_polygons ' . $polyItem['sgp_id'],
PDO::FETCH_ASSOC);
/*
// Alternate way of calling the procedure using PDOStatement; same
leak is present:
$stmt = $dbh->prepare($sql);
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$stmt->execute( array($polyItem['sgp_id']) );
$stmt->closeCursor();
unset($stmt);
*/
unset($polyItemKey);
unset($polyItem);
echo ' memory usage: ' . memory_get_usage(). ' bytes'. PHP_EOL;
}
// When running the script, memory usage just keeps increasing.
Expected result:
I would expect the memory usage of the script to stay constant.
Actual result:
--
Memory usage just keeps increasing.
--
Edit bug report at http://bugs.php.net/bug.php?id=51796&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51796&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51796&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51796&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51796&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51796&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51796&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51796&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51796&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51796&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51796&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51796&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51796&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51796&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51796&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51796&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51796&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51796&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51796&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51796&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51796&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51796&r=mysqlcfg
Bug #51796 [Opn]: Memory leak when executing SQL "EXEC" statements
Edit report at http://bugs.php.net/bug.php?id=51796&edit=1
ID: 51796
User updated by: J dot Antonio at jaruz dot com
Reported by: J dot Antonio at jaruz dot com
Summary: Memory leak when executing SQL "EXEC" statements
Status: Open
Type: Bug
Package: PDO related
Operating System: Ubuntu 10.04 LTS
PHP Version: 5.3.2
New Comment:
I forgot to mention this is using PDO_DBLIB.
Previous Comments:
[2010-05-11 17:48:35] J dot Antonio at jaruz dot com
Description:
On Linux, using PHP 5.3.2-1ubuntu4 with Suhosin-Patch (cli) and FreeTDS
0.82-6build1 (it's a vanilla lucid install, fully up to date):
When executing stored procedures using the "EXEC" SQL statement, both
PDOStatement->execute as well as PDO::query seem to have a memory leak.
We found this while executing a stored procedure within a loop: memory
usage just kept increasing till the memory limit was reached.
Unsetting/nullyfing variables does not help.
The leak is not present (memory usage stays perfectly constant) when
using a "SELECT" SQL statement (which returns the exact same results as
the stored procedure).
I have a feeling PDO is maybe only clearing the memory when it deals
with a "SELECT" statement, and it misses the fact that data can also
come back through "EXEC" statements?
This bug might be slightly related to bug 50755.
Test script:
---
// $polyItemArray is populated with a list of 300 IDs (integers).
// We loop through the array, and execute a stored procedure during each
iteration:
foreach( $polyItemArray as $polyItemKey => $polyItem) {
echo date('H:i:s') . ' | Processing: ' . $polyItem['sgp_id'];
$dbh->query('EXEC proc_map_get_sgp_polygons ' . $polyItem['sgp_id'],
PDO::FETCH_ASSOC);
/*
// Alternate way of calling the procedure using PDOStatement;
same leak is present:
$stmt = $dbh->prepare($sql);
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$stmt->execute( array($polyItem['sgp_id']) );
$stmt->closeCursor();
unset($stmt);
*/
unset($polyItemKey);
unset($polyItem);
echo ' memory usage: ' . memory_get_usage(). ' bytes'. PHP_EOL;
}
// When running the script, memory usage just keeps increasing.
Expected result:
I would expect the memory usage of the script to stay constant.
Actual result:
--
Memory usage just keeps increasing.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51796&edit=1
Bug #51712 [Opn->Csd]: Test mysql_mysqlnd_read_timeout_long must fail on MySQL4
Edit report at http://bugs.php.net/bug.php?id=51712&edit=1 ID: 51712 Updated by: and...@php.net Reported by: post at wickenrode dot com Summary: Test mysql_mysqlnd_read_timeout_long must fail on MySQL4 -Status: Open +Status: Closed Type: Bug Package: MySQL related Operating System: Linux 2.6.18 i686 PHP Version: 5.3.2 -Assigned To: +Assigned To: mysql New Comment: Fixed in 5_3 (will appear in 5.3.3) and trunk. Thank you for bug report Previous Comments: [2010-05-11 17:27:05] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=299250 Log: These tests should be run only if mysqli uses mysqlnd. Part of fix for Bug #51712 Test mysql_mysqlnd_read_timeout_long must fail on MySQL4 [2010-05-01 03:14:50] post at wickenrode dot com Also affects mysqli_stmt_execute.phpt, mysqli_mysqlnd_read_timeout_long.phpt, mysqli_mysqlnd_read_timeout_zero.phpt [2010-05-01 02:58:07] post at wickenrode dot com Description: The test mysql_mysqlnd_read_timeout_long.phpt uses the query "SELECT SLEEP(6)" while SLEEP was only added in MySQL 5.0.12 and therefore the test must fail on MySQL 4 Expected result: Either the test should succeed or XFAIL but not FAIL. -- Edit this bug report at http://bugs.php.net/bug.php?id=51712&edit=1
Bug #49893 [Asn->Csd]: Apache 2.2 Child crash while creating an instance of Zend_Mail_Storage_Pop3
Edit report at http://bugs.php.net/bug.php?id=49893&edit=1
ID: 49893
Updated by: dmi...@php.net
Reported by: greubel at nkey dot de
Summary: Apache 2.2 Child crash while creating an instance of
Zend_Mail_Storage_Pop3
-Status: Assigned
+Status: Closed
Type: Bug
Package: Reproducible crash
Operating System: *
PHP Version: 5.3.0
Assigned To: dmitry
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-05-11 18:09:45] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=299254
Log: Fixed bug #49893 (Crash while creating an instance of
Zend_Mail_Storage_Pop3)
[2010-05-11 16:45:14] dmi...@php.net
The bug occurs when exception is caught in destructor during another
exception processing
Reproduce code:
---
getMessage() . "\n";
}
}
}
class B {
function __construct() {
$this->a = new A();
throw new Exception("1");
}
}
try {
$b = new B();
} catch(Exception $e) {
echo $e->getMessage() . "\n";;
}
?>
Expected result:
2
1
Actual result:
--
2
valgrind
==26823== Invalid read of size 4
==26823==at 0x856480A: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (zend.h:385)
==26823==by 0x84D7B98: execute (zend_vm_execute.h:104)
==26823==by 0x84ACA44: zend_execute_scripts (zend.c:1194)
==26823==by 0x844186E: php_execute_script (main.c:2260)
==26823==by 0x8572CDE: main (php_cli.c:1192)
==26823== Address 0x51f1428 is 8 bytes inside a block of size 20
free'd
==26823==at 0x4B8C90A: free (vg_replace_malloc.c:323)
==26823==by 0x848B079: _efree (zend_alloc.c:2348)
==26823==by 0x849C3E3: _zval_ptr_dtor (zend_execute_API.c:444)
==26823==by 0x84D8156: zend_leave_helper_SPEC
(zend_vm_execute.h:226)
==26823==by 0x84DA521: ZEND_HANDLE_EXCEPTION_SPEC_HANDLER
(zend_vm_execute.h:680)
==26823==by 0x84D7B98: execute (zend_vm_execute.h:104)
==26823==by 0x84ACA44: zend_execute_scripts (zend.c:1194)
==26823==by 0x844186E: php_execute_script (main.c:2260)
==26823==by 0x8572CDE: main (php_cli.c:1192)
[2009-10-20 20:57:38] paj...@php.net
not a bug > bogus.
[2009-10-20 20:13:15] greubel at nkey dot de
Not reproducable
[2009-10-20 20:11:41] greubel at nkey dot de
Please close. I'm not able to reproduce the problem with a small script.
I tried to strip down the code from ZF to provide the same functionality
but provoke the bug. This seems to be not possible on this
circumstances.
This code works well:
sock = fsockopen('pop.gmx.net', 110, $this->errno,
$this->error);
$r = fgets($this->sock);
echo "$r";
fputs($this->sock, "USER mike.greu...@gmx.de\r\n");
$r = fgets($this->sock);
echo "$r";
fputs($this->sock, "PASS \r\n");
$r = fgets($this->sock);
echo "$r";
fputs($this->sock, "QUIT\r\n");
$r = fgets($this->sock);
echo "$r";
}
public function close()
{
fclose($this->sock);
$this->sock = null;
}
}
$bar = new foo();
$bar->close();
?>
So please close.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=49893
--
Edit this bug report at http://bugs.php.net/bug.php?id=49893&edit=1
Bug #51601 [Opn]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1 ID: 51601 Updated by: and...@php.net Reported by: pcarter at jhu dot edu Summary: Segmentation fault when using the 2-argument form of mysql_fetch_array Status: Open Type: Bug Package: MySQL related Operating System: FreeBSD 6.2-RELEASE PHP Version: 5.3.2 Assigned To: mysql New Comment: As a side note, can you try building PHP with the following option --with-mysql=mysqlnd and run the code again? I tried today your script on FreeBSD6 64bit and had no crash, however it was mysqlnd. mysqlnd shouldn't affect this but I want to be sure that this unknown is removed from the equation. Thanks! Previous Comments: [2010-05-11 16:48:06] pcarter at jhu dot edu My test was run initially with PHP compiled from source pulled from php.net, and as noted the problem persisted with php5.3-201004220030, and ldd claims I'm linking against the correct libmysqlclient.so Configure line is: './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--program-prefix=' '--enable-session' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' '--enable-dom' '--enable-json' '--enable-simplexml' '--enable-soap' '--with-openssl' '--with-pgsql' '--with-mysql' '--enable-tokenizer' '--enable-xml' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--enable-cli' '--enable-zip' [2010-05-11 15:25:37] johan...@php.net Could you please provide the configure line. Please also try using plain PHP, not ports which applies random patches we don't control. Please also make sure that you're loading the correct mysql.so in case you're building the mysql extension shared. [2010-04-29 14:47:07] elmex at voll dot in i have problems with mysql_fetch_array($resurce, MYSQL_ASSOC) returning no result set, if i replace it with mysql_fetch_assoc($resurce) it works fine this happens since update to last 5.3 php with freebsd ports [2010-04-22 03:14:55] pcarter at jhu dot edu The problem persists with php5.3-201004220030. The backtrace is identical save instruction addresses. [2010-04-22 02:19:19] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51601 -- Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Bug #51601 [Asn->Fbk]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1 ID: 51601 Updated by: and...@php.net Reported by: pcarter at jhu dot edu Summary: Segmentation fault when using the 2-argument form of mysql_fetch_array -Status: Assigned +Status: Feedback Type: Bug Package: MySQL related Operating System: FreeBSD 6.2-RELEASE PHP Version: 5.3.2 Assigned To: mysql Previous Comments: [2010-05-11 18:24:38] and...@php.net As a side note, can you try building PHP with the following option --with-mysql=mysqlnd and run the code again? I tried today your script on FreeBSD6 64bit and had no crash, however it was mysqlnd. mysqlnd shouldn't affect this but I want to be sure that this unknown is removed from the equation. Thanks! [2010-05-11 16:48:06] pcarter at jhu dot edu My test was run initially with PHP compiled from source pulled from php.net, and as noted the problem persisted with php5.3-201004220030, and ldd claims I'm linking against the correct libmysqlclient.so Configure line is: './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--program-prefix=' '--enable-session' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' '--enable-dom' '--enable-json' '--enable-simplexml' '--enable-soap' '--with-openssl' '--with-pgsql' '--with-mysql' '--enable-tokenizer' '--enable-xml' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--enable-cli' '--enable-zip' [2010-05-11 15:25:37] johan...@php.net Could you please provide the configure line. Please also try using plain PHP, not ports which applies random patches we don't control. Please also make sure that you're loading the correct mysql.so in case you're building the mysql extension shared. [2010-04-29 14:47:07] elmex at voll dot in i have problems with mysql_fetch_array($resurce, MYSQL_ASSOC) returning no result set, if i replace it with mysql_fetch_assoc($resurce) it works fine this happens since update to last 5.3 php with freebsd ports [2010-04-22 03:14:55] pcarter at jhu dot edu The problem persists with php5.3-201004220030. The backtrace is identical save instruction addresses. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51601 -- Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
[PHP-BUG] Req #51797 [NEW]: valid arguments for foreach
From: Operating system: PHP version: 5.2.13 Package: *General Issues Bug Type: Feature/Change Request Bug description:valid arguments for foreach Description: When I give an array to loop through the name of the array and if the array given is with a key, in this case $i, should make no difference. PHP4 didnt make a warning, PHP5 instead does. Test script: --- foreach($array[$i] as $key => $val) results in an warning message. -- Edit bug report at http://bugs.php.net/bug.php?id=51797&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51797&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51797&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51797&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51797&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51797&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51797&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51797&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51797&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51797&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51797&r=support Expected behavior: http://bugs.php.net/fix.php?id=51797&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51797&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51797&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51797&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51797&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51797&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51797&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51797&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51797&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51797&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51797&r=mysqlcfg
Bug #51601 [Fbk->Opn]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1 ID: 51601 User updated by: pcarter at jhu dot edu Reported by: pcarter at jhu dot edu Summary: Segmentation fault when using the 2-argument form of mysql_fetch_array -Status: Feedback +Status: Open Type: Bug Package: MySQL related Operating System: FreeBSD 6.2-RELEASE PHP Version: 5.3.2 Assigned To: mysql New Comment: No change using --with-mysql=mysqlnd =/ Previous Comments: [2010-05-11 18:24:38] and...@php.net As a side note, can you try building PHP with the following option --with-mysql=mysqlnd and run the code again? I tried today your script on FreeBSD6 64bit and had no crash, however it was mysqlnd. mysqlnd shouldn't affect this but I want to be sure that this unknown is removed from the equation. Thanks! [2010-05-11 16:48:06] pcarter at jhu dot edu My test was run initially with PHP compiled from source pulled from php.net, and as noted the problem persisted with php5.3-201004220030, and ldd claims I'm linking against the correct libmysqlclient.so Configure line is: './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--program-prefix=' '--enable-session' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' '--enable-dom' '--enable-json' '--enable-simplexml' '--enable-soap' '--with-openssl' '--with-pgsql' '--with-mysql' '--enable-tokenizer' '--enable-xml' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--enable-cli' '--enable-zip' [2010-05-11 15:25:37] johan...@php.net Could you please provide the configure line. Please also try using plain PHP, not ports which applies random patches we don't control. Please also make sure that you're loading the correct mysql.so in case you're building the mysql extension shared. [2010-04-29 14:47:07] elmex at voll dot in i have problems with mysql_fetch_array($resurce, MYSQL_ASSOC) returning no result set, if i replace it with mysql_fetch_assoc($resurce) it works fine this happens since update to last 5.3 php with freebsd ports [2010-04-22 03:14:55] pcarter at jhu dot edu The problem persists with php5.3-201004220030. The backtrace is identical save instruction addresses. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51601 -- Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Bug #51601 [Opn]: Segmentation fault when using the 2-argument form of mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51601&edit=1 ID: 51601 User updated by: pcarter at jhu dot edu Reported by: pcarter at jhu dot edu Summary: Segmentation fault when using the 2-argument form of mysql_fetch_array Status: Open Type: Bug Package: MySQL related Operating System: FreeBSD 6.2-RELEASE PHP Version: 5.3.2 Assigned To: mysql New Comment: So having not tried any newer snapshots than php5.3-201004220030 I went ahead and grabbed php5.3-201005111430. Using '--with-mysql=mysqlnd' the script executes as expected (no segfault), however, the segfault still occurs with '--with-mysql'. If you'd like I can bisect my way through the snapshots until I find the point at which this became true, but if that's not going to be useful I'd just as soon not. Let me know if I can provide additional information. Previous Comments: [2010-05-11 18:36:23] pcarter at jhu dot edu No change using --with-mysql=mysqlnd =/ [2010-05-11 18:24:38] and...@php.net As a side note, can you try building PHP with the following option --with-mysql=mysqlnd and run the code again? I tried today your script on FreeBSD6 64bit and had no crash, however it was mysqlnd. mysqlnd shouldn't affect this but I want to be sure that this unknown is removed from the equation. Thanks! [2010-05-11 16:48:06] pcarter at jhu dot edu My test was run initially with PHP compiled from source pulled from php.net, and as noted the problem persisted with php5.3-201004220030, and ldd claims I'm linking against the correct libmysqlclient.so Configure line is: './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--program-prefix=' '--enable-session' '--with-apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL' '--prefix=/usr/local' '--enable-dom' '--enable-json' '--enable-simplexml' '--enable-soap' '--with-openssl' '--with-pgsql' '--with-mysql' '--enable-tokenizer' '--enable-xml' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--enable-cli' '--enable-zip' [2010-05-11 15:25:37] johan...@php.net Could you please provide the configure line. Please also try using plain PHP, not ports which applies random patches we don't control. Please also make sure that you're loading the correct mysql.so in case you're building the mysql extension shared. [2010-04-29 14:47:07] elmex at voll dot in i have problems with mysql_fetch_array($resurce, MYSQL_ASSOC) returning no result set, if i replace it with mysql_fetch_assoc($resurce) it works fine this happens since update to last 5.3 php with freebsd ports The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51601 -- Edit this bug report at http://bugs.php.net/bug.php?id=51601&edit=1
Bug #51794 [Opn->Bgs]: String keys in arrays are treated as 0, if not set
Edit report at http://bugs.php.net/bug.php?id=51794&edit=1 ID: 51794 Updated by: dtajchre...@php.net Reported by: schmunk at usrbin dot de Summary: String keys in arrays are treated as 0, if not set -Status: Open +Status: Bogus Type: Bug Package: Arrays related Operating System: OS X 10.6 PHP Version: 5.3.2 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 "Warning Writing to an out of range offset pads the string with spaces. Non-integer types are converted to integer. Illegal offset type emits E_NOTICE. Negative offset emits E_NOTICE in write but reads empty string. Only the first character of an assigned string is used. Assigning empty string assigns NUL byte." See: http://www.php.net/manual/en/language.types.string.php Previous Comments: [2010-05-11 16:07:58] schmunk at usrbin dot de Description: I tried to access an array key by string value. But the variable I accessed was no array, but a string. As stated in the manual you can access single chars by numeric array keys, which makes perfect sense. But if I try to use a string it is treated as 0 (zero). Too much type jugglin'? Test script: --- Expected result: PHP NOTICE - $link['bar'] is not defined. Actual result: -- f -- Edit this bug report at http://bugs.php.net/bug.php?id=51794&edit=1
Bug #51795 [Opn->Bgs]: Loose comparison too loose
Edit report at http://bugs.php.net/bug.php?id=51795&edit=1
ID: 51795
Updated by: dtajchre...@php.net
Reported by: slevinski at gmail dot com
Summary: Loose comparison too loose
-Status: Open
+Status: Bogus
Type: Bug
Package: Strings related
Operating System: Ubuntu
PHP Version: 5.2.13
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
"0080" turns into an 80 and is stored as an int. "80e0" turns into 80 x
10^0 which is also 80 but is stored as a float. 80(int) == 80(float).
80(int) !== 80(float). I didn't understand the rest of what you wrote
but php.net/hexdec might be of some use.
See:
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
Previous Comments:
[2010-05-11 16:25:33] slevinski at gmail dot com
Description:
if ("0080" == "80e0") echo "Smoking crack!";
I created a double octet coded character set. I'm using 4 hex to
represent each character. I'm using a switch statement to get a token
based on the value. The string "80e0" is incorrectly setting off the
case "0080" statement.
The strict comparison of === works as expected, but the switch uses a
loose comparison.
Test script:
---
if ("0080" == "80e0") {
echo "Too loose";
} else {
echo "Just right";
}
Expected result:
Just right
Actual result:
--
Too loose
--
Edit this bug report at http://bugs.php.net/bug.php?id=51795&edit=1
Req #51797 [Opn->Fbk]: valid arguments for foreach
Edit report at http://bugs.php.net/bug.php?id=51797&edit=1
ID: 51797
Updated by: degeb...@php.net
Reported by: rc at opelgt dot org
Summary: valid arguments for foreach
-Status: Open
+Status: Feedback
Type:Feature/Change Request
Package: *General Issues
PHP Version: 5.2.13
New Comment:
The following script works fine for me:
$val) {
echo $key . $val;
}
?>
You'll have to provide a complete script that gives unexpected/incorrect
warnings.
Previous Comments:
[2010-05-11 18:25:31] rc at opelgt dot org
Description:
When I give an array to loop through the name of the array and if the
array given
is with a key, in this case $i, should make no difference.
PHP4 didnt make a warning, PHP5 instead does.
Test script:
---
foreach($array[$i] as $key => $val) results in an warning message.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51797&edit=1
Req #51797 [Fbk->Opn]: valid arguments for foreach
Edit report at http://bugs.php.net/bug.php?id=51797&edit=1
ID: 51797
Updated by: dtajchre...@php.net
Reported by: rc at opelgt dot org
Summary: valid arguments for foreach
-Status: Feedback
+Status: Open
Type:Feature/Change Request
Package: *General Issues
PHP Version: 5.2.13
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
The syntax you provided works just fine and doesn't emit a warning if
$array[$i] is an array... for example:
$array[2] = range(5, 10);
$i = 2;
foreach($array[$i] as $key => $val) echo $key . '->' . $val . PHP_EOL;
Previous Comments:
[2010-05-11 22:39:31] degeb...@php.net
The following script works fine for me:
$val) {
echo $key . $val;
}
?>
You'll have to provide a complete script that gives unexpected/incorrect
warnings.
[2010-05-11 18:25:31] rc at opelgt dot org
Description:
When I give an array to loop through the name of the array and if the
array given
is with a key, in this case $i, should make no difference.
PHP4 didnt make a warning, PHP5 instead does.
Test script:
---
foreach($array[$i] as $key => $val) results in an warning message.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51797&edit=1
Bug #50765 [Com]: Error message executing php - oci.dll was not found
Edit report at http://bugs.php.net/bug.php?id=50765&edit=1 ID: 50765 Comment by: aklobem at gmail dot com Reported by: andreas dot mohr at teraport dot de Summary: Error message executing php - oci.dll was not found Status: Closed Type: Bug Package: Windows Installer Operating System: Windows Server 2006 64bit PHP Version: 5.3.1 Assigned To: jmertic New Comment: This problem is still in place for php-5.2.13-win32-installer.msi Additionally the same error occurred with respect to: PHP_PDO_SQLITE, PHP_PSPELL, PHP_SYBASE_CT Previous Comments: [2010-03-25 20:10:34] jmer...@php.net Verified that pdo_oci extension is not included by default in PHP 5.3.2 installer [2010-01-25 08:52:37] paj...@php.net John, can you disable oci by default please? Alternatively we could add a dep. I'm not sure if oracle has a MSI for the instant client, so we could detect it. [2010-01-15 12:21:05] paj...@php.net Agreed, it should not even be installed by default. [2010-01-15 12:15:34] andreas dot mohr at teraport dot de As mentioned: my problem is actually solved. Nevertheless i consider this to be a bug during installation. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it (disable preset in installation because dependancy raises an error). [2010-01-15 12:12:26] andreas dot mohr at teraport dot de Description: Pre-Installed php 5.2.11 running without error messages. - Initially no oracle extensions were installed After Updating to 5.3.1, running any php command in command window produces the error message "The application has failed to start because oci.dll was not found. Re-Installing the application might solve the "... Reinstalled using php-5.3.1-nts-Win32-VC9-x86.msi... ...with Oracle 10 extension. Did not fix the issue... Result: error now occurs twice when running the php version check Reinstalled once more... ...with 11g Extension. Did not fix the issue... Result: error occurs three times - disabled all extensions containing "oci" in php.ini. Found additional extension extension=php_pdo_oci.dll In previous versions, when PDO extensions are installed no dependancy issues occured when the database (or client) behind the extension was not installed. The necessity to install an oracle client with PHP 5.3.1 is not well documented. So the problem is actually solved. If PDO extension for oracle is installed, the dependancy from oci.dll should be taken care of or informed about during installation. If installation is an update and if pdo for oracle is NOT previously installed, do not install it. Reproduce code: --- In php.ini of a running PHP 5.2.11, only have pdo extensions for mysql installed. Update an installed PHP 5.2.11 to 5.3.1 (with or without oracle extensions) using the windows installer and run c:\your-path-to-php\php-cgi.exe -v in the command prompt. Note: pdo extension is installed (because pdo was previously installed?). Unfolding the tree reveals that the feature is fully installed, including PDO for Oracle 10g client and above. There is no awareness of this. Expected result: Execute php after Update without an error message. Actual result: -- The version info is correctly displayed - following an error message. "The application has failed to start because oci.dll was not found. Re-installing the application might solve the problem." -- Edit this bug report at http://bugs.php.net/bug.php?id=50765&edit=1
Bug #51795 [Bgs]: Loose comparison too loose
Edit report at http://bugs.php.net/bug.php?id=51795&edit=1
ID: 51795
Updated by: ras...@php.net
Reported by: slevinski at gmail dot com
Summary: Loose comparison too loose
Status: Bogus
Type: Bug
Package: Strings related
Operating System: Ubuntu
PHP Version: 5.2.13
New Comment:
Or prefix your strings with 0x if you want to force hex.
Previous Comments:
[2010-05-11 22:18:02] dtajchre...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
"0080" turns into an 80 and is stored as an int. "80e0" turns into 80 x
10^0 which is also 80 but is stored as a float. 80(int) == 80(float).
80(int) !== 80(float). I didn't understand the rest of what you wrote
but php.net/hexdec might be of some use.
See:
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion
[2010-05-11 16:25:33] slevinski at gmail dot com
Description:
if ("0080" == "80e0") echo "Smoking crack!";
I created a double octet coded character set. I'm using 4 hex to
represent each character. I'm using a switch statement to get a token
based on the value. The string "80e0" is incorrectly setting off the
case "0080" statement.
The strict comparison of === works as expected, but the switch uses a
loose comparison.
Test script:
---
if ("0080" == "80e0") {
echo "Too loose";
} else {
echo "Just right";
}
Expected result:
Just right
Actual result:
--
Too loose
--
Edit this bug report at http://bugs.php.net/bug.php?id=51795&edit=1
Bug #47412 [Com]: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI
Edit report at http://bugs.php.net/bug.php?id=47412&edit=1 ID: 47412 Comment by: tser at deltacontrols dot com Reported by: tser at deltacontrols dot com Summary: PHP_MSHUTDOWN_FUNCTION not being called under FastCGI Status: No Feedback Type: Bug Package: CGI related Operating System: win32 only - Vista PHP Version: 5.2.9RC2 Assigned To: pajoye New Comment: More information. Using the latest FastCGI update on IIS7 (KB980363) which support SignalBeforeTerminateSeconds, PHP_MSHUTDOWN_FUNCTION is still not being called. Look into the code in sapi/cgi/fastcgi.c A thread fcgi_shutdown_thread has been created to trap the "_FCGI_SHUTDOWN_EVENT_" event but the code simply set in_shutdown to 1. After that, PHP_MSHUTDOWN_FUNCTION in the extension code is still not being called. Previous Comments: [2010-01-12 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-01-04 18:52:37] tser at deltacontrols dot com To answer the question, the values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests ar eboth 1. But they do not come into play to duplicate this problem. The problem could be duplicated before number of request reach these numbers. I will try to explain the detail using just the standard extension (php_date). 1. Setup PHP FactCGI in IIS. Everything default. 2. Try to run a test.php with this code 3. Attach the debugger to php_cgi.exe and make sure it loaded the debug symbol of php_date. 4. Put a break point in PHP_MSHUTDOWN_FUNCTION inside php_date.c 5. Go to IIS Manager, Application Pools. Select DefaultAppPool and click "Recycle..." on the right hand pane. 6. Notice that the php_cgi.exe will exit but your breakpoint in php_date.c is not triggered. [2010-01-04 14:00:54] paj...@php.net It is called as expected (tested on vista/iis and in the console). If you still experiece this problem, then please provide a detailed way to reproduce: - what are you doing exactly in IIS - values of PHP_FCGI_MAX_REQUESTS and instanceMaxRequests (IIS setting) [2009-12-23 02:27:19] paj...@php.net Will verify this issue once I'm back from vacation. [2009-12-23 02:15:37] liak dot liang at gmail dot com Have the same problem in PHP5.3.0 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47412 -- Edit this bug report at http://bugs.php.net/bug.php?id=47412&edit=1
Bug #51771 [Com]: fclose() seems not to unlock the file
Edit report at http://bugs.php.net/bug.php?id=51771&edit=1 ID: 51771 Comment by: crrodriguez at opensuse dot org Reported by: kulakov74 at yandex dot ru Summary: fclose() seems not to unlock the file Status: Open Type: Bug Package: Filesystem function related Operating System: Linux PHP Version: 5.3.2 New Comment: Correct, take look at the changelog..it clearly says: "Removed automatic file descriptor unlocking happening on shutdown and/or stream close (on all OSes). (Tony, Ilia)" aka. the correct behaviour. Previous Comments: [2010-05-08 11:48:04] kulakov74 at yandex dot ru Description: We have a script that runs in a multiprocess way and it uses flock() for interprocess communication. Things worked fine until we moved to PHP 5.3.2 where all the processes started to hang all of a sudden. I debugged the issues and tried several fixes but they didn't solve it. I made an extensive log of all the script did in order to find out the reason, and I got a situation with 4 scripts running trying to get a non-blocking lock every second, and all of them wrote "lock failed" to the log. At the same time none of them was supposed to hold the lock at that time. Finally I added an flock($hLock, LOCK_UN); before every fclose($hLock); and it is only that that they stopped handing. Test script: --- $H=fopen($LockFile, 'a'); flock($H, LOCK_EX); //... //flock($H, LOCK_UN); - the fix fclose($H); Expected result: no deadlock Actual result: -- Deadlock -- Edit this bug report at http://bugs.php.net/bug.php?id=51771&edit=1
Bug #49349 [Com]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)
Edit report at http://bugs.php.net/bug.php?id=49349&edit=1 ID: 49349 Comment by: viii at iinet dot net dot au Reported by: raulsalitrero at gmail dot com Summary: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors) Status: Assigned Type: Bug Package: Gettext related Operating System: win32 only - windows xp sp3 PHP Version: 5.3.0 Assigned To: pajoye New Comment: Windows Server 2008 R2 x64 with IIS 7.5 PHP 5.3.0, 5.3.2 Locale is English (Australian). Trying to get English (United States) to work. have ./locale/en_AU/LC_MESSAGES/messages.mo ./locale/en_US/LC_MESSAGES/messages.mo Always get the default (Australian) You stated: "The work around is explained in this report." So, but this escapes me. Where is the workaround? I have read this thread several times. Question: why does _SERVER["HTTP_ACCEPT_LANGUAGE"] have en-AU and not en_AU??? Or is this just a silly Winblows thing. Previous Comments: [2010-05-06 09:20:47] paj...@php.net The work around is explained in this report. And yes, there will be a 5.3.3 which will have the fix in the library used by gettext. [2010-05-06 06:00:32] scott at etw dot ca Is there a release date for 5.3.3? Spent the last few months building a project in 5.3 and my final steps was to add language support which i cant do with gettext due to this bug, and to revert to 5.2x would require other major code changes [2010-05-05 12:12:39] sjake_it at hotmail dot com Same problem here with Windows Server 2003 SP2. This bug prevents me from upgrading to php 5.3.x It's been 8 months now so I hope this bug will be fixed quickly now. [2010-04-19 02:00:08] egorinsk at gmail dot com Hi, the same problem here with Windows XP SP2 and PHP 5.3.1 . In PHP 5.2, setlocale() call failed, but gettext() used information from LANG, LC_ALL and LANGUAGE variables. That was good, because I could use putenv() to change gettext() language on Windows and setlocale() on Linux. But now setlocale() on Windows fails, and gettext() always uses system locale, and messages are not translated. Actually, I don't need locales, they only bring problems, I'd prefer to always set it to POSIX locale to get consistent behaviour independent from server setup, but gettext() requires to use it :( [2010-04-14 01:17:18] jorgecanta47 at hotmail dot com Same problem here with Windows Vista Home Premium, PHP 5.3.1 in XAMPP. Is there any workaround yet? Thanks The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49349 -- Edit this bug report at http://bugs.php.net/bug.php?id=49349&edit=1
Req #51797 [Opn->Csd]: valid arguments for foreach
Edit report at http://bugs.php.net/bug.php?id=51797&edit=1
ID: 51797
Updated by: m...@php.net
Reported by: rc at opelgt dot org
Summary: valid arguments for foreach
-Status: Open
+Status: Closed
Type:Feature/Change Request
Package: *General Issues
PHP Version: 5.2.13
-Assigned To:
+Assigned To: mike
Previous Comments:
[2010-05-11 22:51:41] dtajchre...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The syntax you provided works just fine and doesn't emit a warning if
$array[$i] is an array... for example:
$array[2] = range(5, 10);
$i = 2;
foreach($array[$i] as $key => $val) echo $key . '->' . $val . PHP_EOL;
[2010-05-11 22:39:31] degeb...@php.net
The following script works fine for me:
$val) {
echo $key . $val;
}
?>
You'll have to provide a complete script that gives unexpected/incorrect
warnings.
[2010-05-11 18:25:31] rc at opelgt dot org
Description:
When I give an array to loop through the name of the array and if the
array given
is with a key, in this case $i, should make no difference.
PHP4 didnt make a warning, PHP5 instead does.
Test script:
---
foreach($array[$i] as $key => $val) results in an warning message.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51797&edit=1
Req #51797 [Csd->Bgs]: valid arguments for foreach
Edit report at http://bugs.php.net/bug.php?id=51797&edit=1
ID: 51797
Updated by: m...@php.net
Reported by: rc at opelgt dot org
Summary: valid arguments for foreach
-Status: Closed
+Status: Bogus
Type:Feature/Change Request
Package: *General Issues
PHP Version: 5.2.13
Assigned To: mike
Previous Comments:
[2010-05-11 22:51:41] dtajchre...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The syntax you provided works just fine and doesn't emit a warning if
$array[$i] is an array... for example:
$array[2] = range(5, 10);
$i = 2;
foreach($array[$i] as $key => $val) echo $key . '->' . $val . PHP_EOL;
[2010-05-11 22:39:31] degeb...@php.net
The following script works fine for me:
$val) {
echo $key . $val;
}
?>
You'll have to provide a complete script that gives unexpected/incorrect
warnings.
[2010-05-11 18:25:31] rc at opelgt dot org
Description:
When I give an array to loop through the name of the array and if the
array given
is with a key, in this case $i, should make no difference.
PHP4 didnt make a warning, PHP5 instead does.
Test script:
---
foreach($array[$i] as $key => $val) results in an warning message.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51797&edit=1
Bug #51791 [Opn->Bgs]: constant() failed to check undefined constant and php interpreter stoped
Edit report at http://bugs.php.net/bug.php?id=51791&edit=1
ID: 51791
Updated by: m...@php.net
Reported by: iliavlad at mail dot ru
Summary: constant() failed to check undefined constant and php
interpreter stoped
-Status: Open
+Status: Bogus
Type: Bug
Package: Reproducible crash
Operating System: Windows, Linux
PHP Version: 5.3.2
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:
[2010-05-11 12:12:45] iliavlad at mail dot ru
Description:
constant() failed to check undefined constant and php interpreter
stoped, but constant() should return NULL and php interpreter should
continue to work.
Test script:
---
class A
{
const B = 1;
}
var_dump(constant('A::B1'));
echo 5;
Expected result:
Warning: constant(): Couldn't find constant A::B1
NULL
5
Actual result:
--
>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
>php -r "class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;"
>php -r "class A { const B = 1;} var_dump(constant('A::B1')); echo 5;"
Fatal error: Undefined class constant 'A::B1' in Command line code on
line 1
Call Stack:
0.0003 317608 1. {main}() Command line code:0
0.0003 317688 2. constant() Command line code:1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51791&edit=1
Req #51787 [Opn->Bgs]: cloning objects
Edit report at http://bugs.php.net/bug.php?id=51787&edit=1 ID: 51787 Updated by: m...@php.net Reported by: ele_hache at hotmail dot com Summary: cloning objects -Status: Open +Status: Bogus Type: Feature/Change Request Package: *General Issues Operating System: WINDOWS PHP Version: 5.3.2 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: [2010-05-10 20:35:12] ele_hache at hotmail dot com Description: If I have an object that has references to different other objects and even a few collections [arrays] of some even other objects; and I want to make a copy of that instance ?? Must I clone the entire instance structure and performing a clone on every other referenced object and the collections ?? If yes ... What a shit !!! The _clone call should be aware of the other referenced objects inside an object, and do the clone as well. After all, why am I doing a clone, don't you think ?? -- Edit this bug report at http://bugs.php.net/bug.php?id=51787&edit=1
Bug #51785 [Opn->Asn]: No way to escape quotes for XPath
Edit report at http://bugs.php.net/bug.php?id=51785&edit=1
ID: 51785
Updated by: m...@php.net
Reported by: pecoes at gmail dot com
Summary: No way to escape quotes for XPath
-Status: Open
+Status: Assigned
Type: Bug
Package: *XML functions
Operating System: WinXP
PHP Version: 5.3.2
-Assigned To:
+Assigned To: rrichards
Previous Comments:
[2010-05-10 18:43:43] pecoes at gmail dot com
Description:
There seems to be no way to escape single or double quotes for
XPath-Queries.
given: "
/test[text()="\""] produces an error message
/test[text()="\\""] dito
/test[text()="""] finds no match
This is not a PHP-Bug, I suppose. It may be a bug in the libxml2. It
might even be a bug in the XPath Spec itself. But regardless of where
the blame lies: This is serious! How is one supposed to use user-input
in an XPath, if it cannot be escaped?
I found a work-around, but it's fugly:
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
function xquote ($str)
{
if (strpos($str, '"') === FALSE) {
return '"'.$str.'"';
}
if (strpos($str, "'") === FALSE) {
return "'".$str."'";
}
$parts = preg_split('/(")/', $str, 0,
PREG_SPLIT_DELIM_CAPTURE|PREG_SPLIT_NO_EMPTY);
array_walk($parts,
function (&$val) {
if ($val == '"') $val = "'\"'";
else $val = '"'.$val.'"';
}
);
return 'concat('.implode(',', $parts).')';
}
$q = sprintf('/test[text()=%s]', xquote('"'));
if ($xpath->evaluate($q)->item(0)) {
echo 'found'; // works!
} else {
echo 'not found';
}
Test script:
---
$dom = new DOMDocument;
$dom->loadXML('"');
$xpath = new DOMXPath($dom);
$q = '/test[text()="""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
$q = '/test[text()="\\""]';
if ($xpath->evaluate($q)->item(0)) {
echo "found\r\n";
} else {
echo "not found\r\n";
}
Expected result:
found
found
Actual result:
--
not found
Warning: DOMXPath::evaluate(): Invalid predicate...
Warning: DOMXPath::evaluate(): Invalid expression...
Fatal error: Call to a member function item() on non-object...
--
Edit this bug report at http://bugs.php.net/bug.php?id=51785&edit=1
Req #28919 [Opn]: foreach does not take list() as argument output
Edit report at http://bugs.php.net/bug.php?id=28919&edit=1
ID: 28919
User updated by: black at scene-si dot org
Reported by: black at scene-si dot org
Summary: foreach does not take list() as argument output
Status: Open
Type: Feature/Change Request
-Package: Feature/Change Request
+Package: *General Issues
Operating System: any
PHP Version: Irrelevant
New Comment:
It wouldn't be a FEATURE then, would it?
Previous Comments:
[2010-05-11 17:39:51] rc at opelgt dot org
Why not using this code?
foreach ($table as $key=>$val) {
echo $key.":".$val[0].", ".$val[1]."\n";
}
[2004-06-25 19:48:45] poll...@php.net
This is expected behavior. list() is a left-hand language construct and
not currently intended to be used this way.
Reclassifying to Feature/Change Request.
[2004-06-25 13:20:05] black at scene-si dot org
Description:
Requesting additional functionality for foreach?
Reproduce code:
---
$table = array();
$table['username'] = array(1,"John doe");
$table['black'] = array(2,"Jane doe");
$table['yawn'] = array(3,"Undefined");
foreach ($table as $key=>list($id,$title)) {
echo $key.":".$id.", ".$title."\n";
}
foreach ($table as list($id,$title)) {
echo $id.", ".$title."\n";
}
Expected result:
username:1, John doe
black:2, Jane doe
yawn:3, Undefined
1, John doe
2, Jane doe
3, Undefined
Actual result:
--
Parse error
--
Edit this bug report at http://bugs.php.net/bug.php?id=28919&edit=1
