Bug #64986 [Asn-Fbk]: is_readable cannot read UNC path
Edit report at https://bugs.php.net/bug.php?id=64986edit=1 ID: 64986 Updated by: a...@php.net Reported by:mhhechanova at gmail dot com Summary:is_readable cannot read UNC path -Status: Assigned +Status: Feedback Type: Bug Package:*Directory/Filesystem functions Operating System: Windows 64 Bit PHP Version:5.4.5 x64 Assigned To:ab Block user comment: N Private report: N New Comment: Tested again with Win7, Server 2008 and winxp. No reproduce though. Creating files locally on the target server, sharing - and it works. As we cannot debug on your server, lets do another try. The same as you were accessing a share on \\127.0.0.1, please create a test share on the target server, create a file and share it with administrator. You could even try to create that file from the source machine. Then try with your PHP snippet. Previous Comments: [2013-06-12 07:49:19] mhhechanova at gmail dot com @pajoye, thank you for taking time to resolve this issue, however our development server is not connected to the internet. As a reference, here's the server's configuration : - Windows Storage Server 2008 R2 Standard - PHP 5.4.5 x64 thread safe - Apache 2.2.19 x64 - MySQL 5.6.11 x64 Thanks and regard, Mo [2013-06-12 07:43:35] paj...@php.net we can't reproduce it in our (numerous) environment. We have now two ways to solve this issue: - provide access to the host+client so we can debug - give us the exact versions of the windows client and server so we can try using the same configurations in our lab [2013-06-12 06:54:59] mhhechanova at gmail dot com is_readable(127.0.0.1\\test\\test.txt); //returns TRUE However is_readable(servername\\sharename\\file.txt); still returns FALSE ***ALL PERMISSIONS to that folder is set to ALLOW [2013-06-12 06:47:45] a...@php.net Hi, with \\127.0.0.1 i didn't mean explorer. Just create some test share like \\127.0.0.1\test\test.txt and try your PHP snippet. With 'full control' - as it might be different, again - are the checkboxes 'read attributes' and 'read extended attributes' explicitly active on that file? Thanks. [2013-06-11 23:58:56] mhhechanova at gmail dot com @ab, after executing this command : ** What happens if you try to access a share on \\127.0.0.1 ? - A new explorer window opens, displaying the shared folder on my local machine. 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 https://bugs.php.net/bug.php?id=64986 -- Edit this bug report at https://bugs.php.net/bug.php?id=64986edit=1
Req #55694 [Opn-Csd]: Expose additionnal readline variable to prevent default filename completion
Edit report at https://bugs.php.net/bug.php?id=55694edit=1 ID: 55694 Updated by: s...@php.net Reported by:axel dot ml at laposte dot net Summary:Expose additionnal readline variable to prevent default filename completion -Status: Open +Status: Closed Type: Feature/Change Request Package:Readline related PHP Version:5.3.8 -Assigned To: +Assigned To:stas Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Pull merged into 5.4 and above. Previous Comments: [2011-09-14 14:42:42] axel dot ml at laposte dot net Description: Actually, when using a custom completion function with readline_completion_function(), if this custom completion function does not find any match, it falls back to the default filename completion. In order to prevent this behaviour, the C API of readline provides a variable named rl_attempted_completion_over. Defining this variable to a non-zero value disables the uses of the default filename completion. This variable is not exposed to PHP and the filename completion cannot be bypassed. The provided patch exposes this variable to PHP, and allows to use readline_info(attempted_completion_over, 1) in the PHP completion function to prevent default filename completion to occurs. There is a bug report but it s closed since 2005 https://bugs.php.net/bug.php?id=31796 Another bug report for this https://bugs.php.net/bug.php?id=48089 with a patch which does the job but in a wrong way, imo. -- Edit this bug report at https://bugs.php.net/bug.php?id=55694edit=1
Bug #48724 [Asn-Csd]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR
Edit report at https://bugs.php.net/bug.php?id=48724edit=1 ID: 48724 Updated by: s...@php.net Reported by:an0nym at narod dot ru Summary:getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: * PHP Version:5.3.0 Assigned To:mysql Block user comment: N Private report: N New Comment: Automatic comment on behalf of t...@daylessday.org Revision: http://git.php.net/?p=php-src.git;a=commit;h=95cc763a1484c4922f6577c10de937299dc8c8e0 Log: fix bug #48724 Previous Comments: [2012-04-16 12:12:38] tony2...@php.net Ulf, could you pls check if the attached patch is correct? Thanks. [2012-04-13 12:06:15] tony2...@php.net The following patch has been added/updated: Patch Name: fix-bug-48724.patch Revision: 1334318775 URL: https://bugs.php.net/patch-display.php?bug=48724patch=fix-bug-48724.patchrevision=1334318775 [2009-07-03 16:57:28] u...@php.net You are free to patch it. Bye. [2009-07-03 16:30:12] an0nym at narod dot ru Poor MySQLi developers... they've managed to solve this problem without specification. Poor you... you've spent sooo many time for nothing developing this function, which works in 35 of 38 cases - this stuff has no specification! Wait for a specification - you have a good excuse! Bye. [2009-07-03 16:17:20] u...@php.net You are free to write a patch. I refuse to work on stuff that has no specification and which may go into any direction. That typically ends up in a backwards compatibility nightmare, which in particular for an abstraction like PDO makes no sense to me. The patch may be rather simple. But watch out for different values returned by different MySQL versions. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48724 -- Edit this bug report at https://bugs.php.net/bug.php?id=48724edit=1
Bug #64722 [Asn-Csd]: PDO extension causes zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=64722edit=1
ID: 64722
User updated by:tj dot botha at plista dot com
Reported by:tj dot botha at plista dot com
Summary:PDO extension causes zend_mm_heap corrupted
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Ubuntu Server 12.10
PHP Version:master-Git-2013-04-26 (Git)
Block user comment: N
Private report: N
New Comment:
Hey guys - thanks so much for fixing this - I checked out git commit
1143f58a7094ed9a4960bfb714fa2773dda7c704, built it and can confirm its no
longer
segfaulting.
cool thanks :)
Previous Comments:
[2013-06-14 10:35:34] tj dot botha at plista dot com
Ok - so I managed to create a script which breaks it:
namespace SomeName\db;
class PDO extends \PDO {
public $name;
public function setName($name) {
$this-name = $name;
}
}
class DatabaseManager {
private static $connections;
private static $options = array(
PDO::ATTR_PERSISTENT = 1
);
public static function createConnection($name)
{
$pdo = null;
$pdo = new
PDO(mysql:host=localhost;port=3306;dbname=db_youfilter, root, lmnop,
self::$options);
self::$connections[$name] = $pdo;
}
}
DatabaseManager::createConnection(foo);
DatabaseManager::createConnection(bar);
Turns out this is a similar bug to
https://bugs.php.net/bug.php?id=63176
And this issue is still open.
We will probably work around this problem by not extending PDO.
[2013-06-12 08:57:49] tj dot botha at plista dot com
This issue can be closed - There is a problem between the combination of ( or
rather lack of using imagick ), pdo, and the error handling, and possibly the
logging system, unique to the site and not 100% reproducible using a reduced
test script (and I also do not want spend a whole day writing one)
using imagick 3 RC 2 with pdo enabled works for now.
If you want to reproduce the behavior, attempt to imagine the circumstances in
which zend_object_std_dtor gets called twice for the same object.
[2013-05-02 15:08:42] tj dot botha at plista dot com
Even more correct:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
object-guards = NULL;
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
object-properties = NULL;
}
if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
object-properties_table[i] = NULL;
}
}
efree(object-properties_table);
object-properties_table = NULL;
}
}
[2013-05-02 14:42:26] tj dot botha at plista dot com
In my mind, the correct function should look like this (without knowing the
exact context in which it runs)
//source_code/Zend/zend_objects.c:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
}
if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
object-properties_table[i] = NULL;
}
}
efree(object-properties_table);
object-properties_table = NULL;
}
}
However, this appears in my apache logs, only when running in debug mode:
[Thu May 02 16:41:28.476657 2013] [auth_digest:notice] [pid 23396] AH01757:
generating secret for digest authentication ...
[Thu May 02 16:41:29.052276 2013] [ssl:warn] [pid 23396] AH01873: Init: Session
Cache is not configured [hint: SSLSessionCache]
[Thu May 02 16:41:29.052747 2013] [lbmethod_heartbeat:notice] [pid 23396]
AH02282: No
Bug #63176 [Com]: Segmentation fault when instantiate 2 persistent PDO to the same db server
Edit report at https://bugs.php.net/bug.php?id=63176edit=1 ID: 63176 Comment by: tj dot botha at plista dot com Reported by:jrbasso at gmail dot com Summary:Segmentation fault when instantiate 2 persistent PDO to the same db server Status: Closed Type: Bug Package:PDO related Operating System: Ubunt 12.04.1 PHP Version:5.4.7 Assigned To:wez Block user comment: N Private report: N New Comment: Hey guys - thanks very much for fixing this! I pulled 1143f58a7094ed9a4960bfb714fa2773dda7c704 this morning and confirm we're also no longer segfaulting. :) Previous Comments: [2013-06-16 15:02:30] larue...@php.net @wez what do you think? thanks [2013-06-16 15:01:46] larue...@php.net bug has been fixed, will behavior like 5.3 but it's a little weird that's two different drived class will share one same dbh, and the dbh hold only one drived class instance. see the test script I committed: https://github.com/php/php- src/blob/6cd6349ff8842a9356723b7b192eb3c93fb64c7e/ext/pdo_mysql/tests/bug63176.php t note the result are all PDO2 maybe we should also add the drived class name into the persistent id? thanks [2013-06-16 14:57:04] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=49e57a31659a82443b9413127f8d58a72f09ed5b Log: Fixed bug #63176 (Segmentation fault when instantiate 2 persistent PDO to the same db server) [2013-06-14 19:31:44] jrbasso at gmail dot com @thz, the workaround I did was to create 2 DNS names for the same DB. So PHP will think they are 2 different servers and connect twice. [2013-06-14 13:16:48] thz at plista dot com Hi, we are experiencing the same error and it's preventing us from moving to PHP 5.4. Are there any plans to fix this or are we going to have to live with not being able to derive from PDO? We have done extensive debugging and may be able to provide some information as to why this happens, but due to a lack of internal knowledge of how the Zend engine works, we haven't been able to come up with a fix. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63176 -- Edit this bug report at https://bugs.php.net/bug.php?id=63176edit=1
Bug #50688 [Com]: Using exceptions inside usort() callback function causes a warning
Edit report at https://bugs.php.net/bug.php?id=50688edit=1 ID: 50688 Comment by: andrejs dot verza at gmail dot com Reported by:jcampbell at remindermedia dot com Summary:Using exceptions inside usort() callback function causes a warning Status: Assigned Type: Bug Package:Arrays related Operating System: Fedora Core 12 PHP Version:5.*, 6 Assigned To:stas Block user comment: N Private report: N New Comment: Php 5.4.16 also fails with this. Still the same status for 3 and a half years old bug?! Previous Comments: [2012-08-08 17:53:58] mbrowne83 at gmail dot com This will probably be obvious to most, but I just wanted to mention that you can always prefix the usort function with the @ symbol to prevent the warning...of course that would also suppress any other types of notices or warnings that might occcur anywhere within the sorting function... [2012-02-24 18:04:02] keith at breadvault dot com This same problem arises when using Mockery to mock the object whose method is being used by usort(), even though the method itself neither is mocked nor handles any exceptions. The proxy generated by Mockery must wrap the target class's methods with some exception-handling code. Unfortunately this forced me to code a workaround that would not use usort. My hack extracts from the objects in the array the values being sorted on, sorts that array of values using asort() (to preserve the keys), and finally rebuilds the list of objects using the keys in the order that they appear in the asorted list of values. Yuck. [2012-02-21 22:56:31] eric_haney at yahoo dot com It took me a while to figure out that some code called from usort was throwing, catching, and (gracefully) handling an Exception. Then I found this post. Quite frustrating. I turned off warnings with ini_set before calling usort, then turned them on again after. This is an effective workaround for now, but I'd love to clean that nastiness out of my code. It is also my opinion that usort should be allowed to change the elements in the array. EG: an instance variable of an object may be lazy-loaded as a result of a method call from within a usort callback. Should a warning really be issued in that case? [2011-10-10 21:44:56] poehler at interworx dot com This bug is still present as of PHP 5.3.8, we ran into it today and spent most of a day trying to figure out what was causing the error message Array was modified by the user comparison function, when CLEARLY, NOTHING was changing the array at all! The exception was not thrown/caught directly in the usort function but rather in a constructor of a class that was called about 3 or 4 functions deep from the usort, making it very difficult to track down. After finally figuring out the exception was somehow related, we searched google and found this bug report. I'm sure we can agree that the minor act of catching an exception should not result in usort throwing a warning message. This bug is a huge timewaster :( [2010-10-07 23:34:54] philipwhiuk at hotmail dot com I notice this is still affecting PHP 5.3.3 (Windows/Apache install). Is this likely to be fixed soon - is it a question of developer time and priority or is it too difficult to fix? It's quite irritating - I realise that the obvious solution is to avoid throwing the exception (ha-ha) but it's a useful function and exceptions are... inevitable. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=50688 -- Edit this bug report at https://bugs.php.net/bug.php?id=50688edit=1
Bug #18739 [Nab]: Comparing integer 0 to string 'NULL'
Edit report at https://bugs.php.net/bug.php?id=18739edit=1
ID: 18739
User updated by:test at test dot fr
Reported by:test at test dot fr
Summary:Comparing integer 0 to string 'NULL'
Status: Not a bug
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:4.1.2
Block user comment: N
Private report: N
New Comment:
This is not a bug.
Previous Comments:
[2011-10-03 13:11:40] phpbm at fr dot fr
This is not a bug.
[2002-08-05 04:48:23] san...@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
[2002-08-05 04:04:05] test at test dot fr
?php
if (0 == 'NULL') {
echo toto;
}
?
It looks as if string 'NULL' matches integer 0.
--
Edit this bug report at https://bugs.php.net/bug.php?id=18739edit=1
Bug #65045 [Opn-Ver]: mb_convert_encoding breaks well-formed character
Edit report at https://bugs.php.net/bug.php?id=65045edit=1
ID: 65045
Updated by: a...@php.net
Reported by:masakielastic at gmail dot com
Summary:mb_convert_encoding breaks well-formed character
-Status: Open
+Status: Verified
Type: Bug
Package:mbstring related
Operating System: Mac OSX
PHP Version:5.5.0RC3
Block user comment: N
Private report: N
New Comment:
I can reproduce that on windows too, the issue is probably not only osx. Here's
slightly modified snippet:
?php
$str1 = \xF0\xA4\xAD . \xF0\xA4\xAD\xA2 . \xF0\xA4\xAD\xA2;
$exp1 = \xEF\xBF\xBD . \xF0\xA4\xAD\xA2 . \xF0\xA4\xAD\xA2;
if (true !== mb_substitute_character(0xFFFD)) {
die(can't set substitute char\n);
}
print_hex($str1);
$s = mb_convert_encoding($str1, 'UTF-8', mb_detect_encoding($str1));
print_hex($s);
function print_hex($s)
{
for ($i = 0; $i strlen($s); $i++) {
echo 0x, dechex(ord($s[$i])), ;
}
echo \n;
}
?
And the output (added pipes as utf8 char separators manually)
0xf0 0xa4 0xad | 0xf0 0xa4 0xad 0xa2 | 0xf0 0xa4 0xad 0xa2
0xef 0xbf 0xbd | 0xef 0xbf 0xbd | 0xef 0xbf 0xbd | 0xef 0xbf 0xbd | 0xf0 0xa4
0xad 0xa2
As one can see, the first original invalid 3 byte sequence and the second valid
4 byte sequence are replaced with 0xef 0xbf 0xbd, the last one remains.
However looking at the codes only libmfl is in the game
there http://lxr.php.net/xref/PHP_5_5/ext/mbstring/mbstring.c#3011 . Not sure
yet to have overseen something, have to make a C
snippet.
Previous Comments:
[2013-06-16 23:17:01] masakielastic at gmail dot com
Description:
When converting string from UTF-8 to UTF-8 by using mb_convert_encoding for
replacing ill-formed byte sequence with the substitute character(U+FFFD),
mb_convert_encoding replaces the character follwing ill-formed byte sequence
with
the substitute character. mb_convert_encoding also delete trailing ill-formed
byte
sequence and doesn't replace it with the substitute character.
The comprehensive test case for 2-4 byte
characters is here: https://gist.github.com/masakielastic/5793665 .
Test script:
---
// U+24B62: \xF0\xA4\xAD\xA2
// ill-formed: \xF0\xA4\xAD
// U+FFFD: \xEF\xBF\xBD
$str = \xF0\xA4\xAD. \xF0\xA4\xAD\xA2.\xF0\xA4\xAD\xA2;
$expected = \xEF\xBF\xBD.\xF0\xA4\xAD\xA2.\xF0\xA4\xAD\xA2;
$str2 = \xF0\xA4\xAD\xA2.\xF0\xA4\xAD\xA2.\xF0\xA4\xAD;
$expected2 = \xF0\xA4\xAD\xA2.\xF0\xA4\xAD\xA2.\xEF\xBF\xBD;
mb_substitute_character(0xFFFD);
var_dump(
$expected === htmlspecialchars_decode(htmlspecialchars($str,
ENT_SUBSTITUTE, 'UTF-8')),
$expected2 === htmlspecialchars_decode(htmlspecialchars($str2,
ENT_SUBSTITUTE, 'UTF-8')),
$expected === mb_convert_encoding($str, 'UTF-8', 'UTF-8'),
$expected2 === mb_convert_encoding($str2, 'UTF-8', 'UTF-8')
);
Expected result:
bool(true)
bool(true)
bool(true)
bool(true)
Actual result:
--
bool(true)
bool(true)
bool(false)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65045edit=1
[PHP-BUG] Bug #65047 [NEW]: Test skip on client / server version
From: remi
Operating system: GNU/Linux
PHP version: 5.4.16
Package: PostgreSQL related
Bug Type: Bug
Bug description:Test skip on client / server version
Description:
Hi,
Running the php test suite, using a client library version 8.4.13 (RHEL-6)
against a server running version 9.2.4 (RHEL-6 + RHSCL 1.0beta) reports
some failures
/tmp/php-5.4.16/ext/pgsql/tests/08escape.phpt
/tmp/php-5.4.16/ext/pgsql/tests/10pg_convert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/12pg_insert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/14pg_update_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/18pg_escape_bytea.phpt
/tmp/php-5.4.16/ext/pgsql/tests/bug37100_85.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274_2.phpt
For example PQunescapeBytea function is a pure client side function. So
result depends on the client version, not on the server version.
Proposal, keep (or add where is missing):
skip_server_version('8.5dev', '');
And add:
skip_client_version('8.5dev', '');
I agree, using a 8.4 client to access a 9.2 server is something which
should be avoid...
What is your thoughts ?
(I prefer asking before committing something perhaps stupid)
--
Edit bug report at https://bugs.php.net/bug.php?id=65047edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65047r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65047r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65047r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65047r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65047r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65047r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65047r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65047r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65047r=support
Expected behavior: https://bugs.php.net/fix.php?id=65047r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65047r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65047r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65047r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65047r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65047r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65047r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65047r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65047r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65047r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65047r=mysqlcfg
Bug #65047 [Com]: Test skip on client / server version
Edit report at https://bugs.php.net/bug.php?id=65047edit=1
ID: 65047
Comment by: r...@php.net
Reported by:r...@php.net
Summary:Test skip on client / server version
Status: Open
Type: Bug
Package:PostgreSQL related
Operating System: GNU/Linux
PHP Version:5.4.16
Block user comment: N
Private report: N
New Comment:
On a opposite side pgsql/tests/bug37100.phpt could use
skip_client_version('8.5dev', '=');
It will be run and will succeed with client version 8.4
Previous Comments:
[2013-06-17 13:11:33] r...@php.net
Description:
Hi,
Running the php test suite, using a client library version 8.4.13 (RHEL-6)
against a server running version 9.2.4 (RHEL-6 + RHSCL 1.0beta) reports some
failures
/tmp/php-5.4.16/ext/pgsql/tests/08escape.phpt
/tmp/php-5.4.16/ext/pgsql/tests/10pg_convert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/12pg_insert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/14pg_update_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/18pg_escape_bytea.phpt
/tmp/php-5.4.16/ext/pgsql/tests/bug37100_85.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274_2.phpt
For example PQunescapeBytea function is a pure client side function. So result
depends on the client version, not on the server version.
Proposal, keep (or add where is missing):
skip_server_version('8.5dev', '');
And add:
skip_client_version('8.5dev', '');
I agree, using a 8.4 client to access a 9.2 server is something which should be
avoid...
What is your thoughts ?
(I prefer asking before committing something perhaps stupid)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65047edit=1
[PHP-BUG] Bug #65050 [NEW]: zend_hash_apply not interruption safe
From: nikic
Operating system:
PHP version: 5.5.0RC3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:zend_hash_apply not interruption safe
Description:
The zend_hash_apply is used all over the place, but it isn't interruption
safe (just like iteration using HashPosition).
Here is an example making use of OB callbacks in var_dump:
?php
$array1 = [0, 1];
$array2 = [$array1];
ob_start(function($str) use($array1) {
static $i = 0;
if ($i++ == 4) {
unset($array1[0]);
//unset($array1[1]);
}
return $i: $str;
}, 1);
var_dump($array2);
nikic@pluto:~/dev/php-dev$ sapi/cli/php t16.php
1: array(1) {
2: [0]=
3: 4: array(2) {
5: [0]=
6: Segmentation fault (core dumped)
Valgrind output (only first entry):
==11997== Invalid read of size 4
==11997==at 0x819057F: php_var_dump (var.c:99)
==11997==by 0x81903EF: php_array_element_dump (var.c:51)
==11997==by 0x827C917: zend_hash_apply_with_arguments
(zend_hash.c:748)
==11997==by 0x8190A58: php_var_dump (var.c:146)
==11997==by 0x81903EF: php_array_element_dump (var.c:51)
==11997==by 0x827C917: zend_hash_apply_with_arguments
(zend_hash.c:748)
==11997==by 0x8190A58: php_var_dump (var.c:146)
==11997==by 0x8190C07: zif_var_dump (var.c:183)
==11997==by 0x82A72BA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:547)
==11997==by 0x82ABD3F: ZEND_DO_FCALL_SPEC_CONST_HANDLER
(zend_vm_execute.h:2328)
==11997==by 0x82A67F6: execute_ex (zend_vm_execute.h:356)
==11997==by 0x82A68AB: zend_execute (zend_vm_execute.h:381)
==11997== Address 0x447f15c is 12 bytes inside a block of size 36 free'd
==11997==at 0x402B06C: free (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==11997==by 0x823257E: _efree (zend_alloc.c:2437)
==11997==by 0x827C09B: zend_hash_del_key_or_index (zend_hash.c:512)
==11997==by 0x82FC731: ZEND_UNSET_DIM_SPEC_CV_CONST_HANDLER
(zend_vm_execute.h:33119)
==11997==by 0x82A67F6: execute_ex (zend_vm_execute.h:356)
==11997==by 0x82A68AB: zend_execute (zend_vm_execute.h:381)
==11997==by 0x8258E71: zend_call_function (zend_execute_API.c:939)
==11997==by 0x8277CD4: zend_fcall_info_call (zend_API.c:3381)
==11997==by 0x81E7B47: php_output_handler_op (output.c:962)
==11997==by 0x81E8026: php_output_op (output.c:1063)
==11997==by 0x81E5E6C: php_output_write (output.c:255)
==11997==by 0x81C9442: php_printf (main.c:682)
--
Edit bug report at https://bugs.php.net/bug.php?id=65050edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65050r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65050r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65050r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65050r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65050r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65050r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65050r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65050r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65050r=support
Expected behavior: https://bugs.php.net/fix.php?id=65050r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65050r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65050r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65050r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65050r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65050r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65050r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65050r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65050r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65050r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65050r=mysqlcfg
[PHP-BUG] Bug #65051 [NEW]: count() off by one inside unset()
From: nikic
Operating system:
PHP version: 5.5.0RC3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:count() off by one inside unset()
Description:
If code is run inside an array offset unset the reported size of that array
will be off by one:
?php
class Foo {
public $array;
public function __destruct() {
var_dump(count($this-array[0]));
var_dump($this-array[0]);
}
}
$array = [[new Foo]];
$array[0][0]-array = $array;
unset($array[0][0]);
Outputs:
int(1)
array(1) {
}
The reason is that zend_hash_del_key_or_index decrements the element count
*after* calling the bucket dtor.
--
Edit bug report at https://bugs.php.net/bug.php?id=65051edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65051r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65051r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65051r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65051r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65051r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65051r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65051r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65051r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65051r=support
Expected behavior: https://bugs.php.net/fix.php?id=65051r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65051r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65051r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65051r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65051r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65051r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65051r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65051r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65051r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65051r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65051r=mysqlcfg
Bug #65051 [Opn-Csd]: count() off by one inside unset()
Edit report at https://bugs.php.net/bug.php?id=65051edit=1
ID: 65051
Updated by: ni...@php.net
Reported by:ni...@php.net
Summary:count() off by one inside unset()
-Status: Open
+Status: Closed
Type: Bug
Package:Scripting Engine problem
PHP Version:5.5.0RC3
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of nikic
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=86434be9462c5b14dccc588afe6bc1b4a1433360
Log: Fix bug #65051: count() off by one inside unset()
Previous Comments:
[2013-06-17 19:05:38] ni...@php.net
Description:
If code is run inside an array offset unset the reported size of that array
will be off by one:
?php
class Foo {
public $array;
public function __destruct() {
var_dump(count($this-array[0]));
var_dump($this-array[0]);
}
}
$array = [[new Foo]];
$array[0][0]-array = $array;
unset($array[0][0]);
Outputs:
int(1)
array(1) {
}
The reason is that zend_hash_del_key_or_index decrements the element count
*after* calling the bucket dtor.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65051edit=1
Bug #65053 [Opn-Nab]: \' interpreted as \' instead of just '
Edit report at https://bugs.php.net/bug.php?id=65053edit=1
ID: 65053
Updated by: ahar...@php.net
Reported by:d_sandlin at email dot com
Summary:\' interpreted as \' instead of just '
-Status: Open
+Status: Not a bug
Type: Bug
-Package:PHP options/info functions
+Package:MySQL related
Operating System: Windows 8
PHP Version:5.4.16
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2013-06-17 22:26:45] d_sandlin at email dot com
Description:
When I enter INSERT INTO 'members' ('webmaster', 'abcd') directly into
phpMyAdmin, a record is added to table members with the appropriate values.
I've tried several other variations and can't add the record with code.
Here is my .htaccess file:
RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html
I had to add that to get php to work within an html file.
My host is arvixe - Linux hosting
Test script:
---
\\(where $uname = webmaster and $pword = abcd, and the $db_variables
assigned
\\ This is in an included file, db_connect.php
8 $mysqli = new mysqli($host, $db_username, $db_password, $db_name);
9 if ($mysqli-connect_errno) {
10echo Failed to connect to MySQL: ( . $mysqli-connect_errno . ) .
$mysqli-connect_error;
} // This is where I'm having trouble: the \' characters aren't working as '.
22 $qtext = INSERT INTO \'members\' (\' . $uname . \' , \' . $pword .
\');
23 echo $qtext;
24 if (!$mysqli-query($qtext)) {
25 echo Table insertion failed: ( . $mysqli-errno . ) .
$mysqli-error;
26}
Expected result:
I expect a record to be added to table 'members' with the following field
values:
(there are only 3 fields: id int(4)(autoincrement), username varchar(65),
password
varchar(65))
id = 6 (or some number), username = webmaster, password = abcd
Actual result:
--
This from the echo $qtext, the if(), and the SQL server:
INSERT INTO \'members\' (\'webmaster\' , \'abcd\')Table insertion failed:
(1064)
You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near '\'members\'
(\'webmaster\'
, \'abcd\')' at line 1
-
The backslash code is not translating special characters. \' should be
interpreted as a single quote, but it isn't.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65053edit=1
Bug #60560 [Com]: SplFixedArray un-/serialize, getSize(), count() return 0, keys are strings
Edit report at https://bugs.php.net/bug.php?id=60560edit=1
ID: 60560
Comment by: rewilliams at newtekemail dot com
Reported by:digital1kk at interia dot pl
Summary:SplFixedArray un-/serialize, getSize(), count()
return 0, keys are strings
Status: Closed
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
It appears this is fixed in 5.5 but not 5.4.x, at least not as of 5.4.13, which
is
the latest to which I have access.
Is there any chance the fix will be back-ported to 5.4?
Previous Comments:
[2012-08-03 14:36:06] php at maisqi dot com
Hello. This is not really fixed. I still got this error on PHP 5.4.5. I don't
believe that the said fix wasn't released in six months, so something is wrong.
So, is this going to be reopen or should I file a new bug?
[2012-06-18 15:57:56] php at maisqi dot com
Hello. I'm experiencing this problem in Windows and Linux, PHP 5.4.4 and PHP
5.3.3. I argue it's not resolved again.
I wrote a demo at http://maisqi.com/outros/bugs/php/SplFixedArraySerialization
and I'd appreciate if someone else makes his own tests. Here is the demo source
code:
!DOCTYPE html
html
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleSplFixedArray Serialization/title
/head
body
p
An unserialized SplFixedArray loses it's element count, though it keeps
the
elements. This seems to be
a href=https://bugs.php.net/bug.php?id=60560amp;edit=1;Bug
#60560/a all
over again.
/p
p
This demo runs on a PHP 5.3.3 CGI under Apache and Linux. Also tested it
on a PHP 5.4.4 running as a Apache 2 module under Windows 7 32 bits,
with
same results.
/p
hr /
pre
?php
$fn = 'serial.txt';
$x = new SplFixedArray (4);
$x [0] = 123;
$x [1] = 456;
$x [2] = 789;
$x [3] = 'abc';
echo strongSplFixedArray to serialize/strong:\n;
print_r ($x);
echo \ncount: strong, $x-getSize (), /strong;
echo \nstrongFirst element/strong: ;
try { $o = $x [0];} catch (Exception $e) {$o = 'Error!'; }
echo strong$o/strong\n;
echo \n\nSerializing to file \$fn\...\n;
file_put_contents ($fn, serialize ($x));
echo \n\nUnserializing from file \$fn\...\n;
$x = unserialize (file_get_contents ($fn));
echo \n\nstrongUnserialized SplFixedArray/strong:\n;
print_r ($x);
echo \ncount: strong, $x-getSize (), /strong;
echo \nstrongFirst element/strong: ;
try { $o = $x [0];} catch (Exception $e) {$o = 'Error!'; }
echo strong$o/strong\n;
if ($buf = @file_get_contents ('error_log')) {
echo \n\nstrongLast errors/strong:\n, $buf;
}
?
/pre
/body
/html
[2012-02-21 10:34:50] ahar...@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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Fixed on trunk.
[2012-02-21 10:34:39] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=323408
Log: Add a __wakeup() method to SplFixedArray, thereby fixing serialising an
SplFixedArray object and bug #60560 (SplFixedArray un-/serialize, getSize(),
count() return 0, keys are strings).
[2011-12-19 13:49:25] digital1kk at interia dot pl
Quick fix is to store in serialized form internal array:
-
$sa = serialize($a-toArray());
$ua = unserialize($sa);
$b = SplFixedArray::fromArray($ua);
var_dump($b);
echo 'Sizeof $b = ' . $b-getSize(), PHP_EOL;
echo 'Count $b = ' . $b-count(), PHP_EOL;
-
Gives the expected results
Also I forgot in php = 5.4.0RC3 (should I report this as separate bug?)
The actual result of var_dump($b) is:
$b = object(SplFixedArray)#2 (2) {
[0]=
int(1)
[1]=
int(2)
}
The keys are strings and not integers and this causes
-
$b = unserialize(serialize($a));
SplFixedArray::fromArray($b-toarray());
-
To throw an exception 'InvalidArgumentException' with message 'array must
contain only positive integer keys'
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
[PHP-BUG] Bug #65053 [NEW]: \' interpreted as \' instead of just '
From: d_sandlin at email dot com
Operating system: Windows 8
PHP version: 5.4.16
Package: PHP options/info functions
Bug Type: Bug
Bug description:\' interpreted as \' instead of just '
Description:
When I enter INSERT INTO 'members' ('webmaster', 'abcd') directly into
phpMyAdmin, a record is added to table members with the appropriate
values.
I've tried several other variations and can't add the record with code.
Here is my .htaccess file:
RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html
I had to add that to get php to work within an html file.
My host is arvixe - Linux hosting
Test script:
---
\\(where $uname = webmaster and $pword = abcd, and the $db_variables
assigned
\\ This is in an included file, db_connect.php
8 $mysqli = new mysqli($host, $db_username, $db_password, $db_name);
9 if ($mysqli-connect_errno) {
10echo Failed to connect to MySQL: ( . $mysqli-connect_errno . )
. $mysqli-connect_error;
} // This is where I'm having trouble: the \' characters aren't working
as '.
22 $qtext = INSERT INTO \'members\' (\' . $uname . \' , \' . $pword .
\');
23 echo $qtext;
24 if (!$mysqli-query($qtext)) {
25 echo Table insertion failed: ( . $mysqli-errno . ) .
$mysqli-error;
26}
Expected result:
I expect a record to be added to table 'members' with the following field
values:
(there are only 3 fields: id int(4)(autoincrement), username varchar(65),
password
varchar(65))
id = 6 (or some number), username = webmaster, password = abcd
Actual result:
--
This from the echo $qtext, the if(), and the SQL server:
INSERT INTO \'members\' (\'webmaster\' , \'abcd\')Table insertion failed:
(1064)
You have an error in your SQL syntax; check the manual that corresponds to
your
MySQL server version for the right syntax to use near '\'members\'
(\'webmaster\'
, \'abcd\')' at line 1
-
The backslash code is not translating special characters. \' should be
interpreted as a single quote, but it isn't.
--
Edit bug report at https://bugs.php.net/bug.php?id=65053edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65053r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65053r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65053r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65053r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65053r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65053r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65053r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65053r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65053r=support
Expected behavior: https://bugs.php.net/fix.php?id=65053r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65053r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65053r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65053r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65053r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65053r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65053r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65053r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65053r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65053r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65053r=mysqlcfg
[PHP-BUG] Bug #65054 [NEW]: Call-time pass-by-reference has been removed
From: stefanmruk at yahoo dot co dot uk Operating system: linux PHP version: 5.4.16 Package: Scripting Engine problem Bug Type: Bug Bug description:Call-time pass-by-reference has been removed Description: Why Test script: --- if ( method_exists( $obj, init ) ) if(PHP_VERSION_ID 5 ) $obj-init($this); else $obj-init($this); -- Edit bug report at https://bugs.php.net/bug.php?id=65054edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65054r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65054r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65054r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65054r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65054r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65054r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65054r=needscript Try newer version: https://bugs.php.net/fix.php?id=65054r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65054r=support Expected behavior: https://bugs.php.net/fix.php?id=65054r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65054r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65054r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65054r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65054r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65054r=dst IIS Stability: https://bugs.php.net/fix.php?id=65054r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65054r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65054r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65054r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65054r=mysqlcfg
Bug #65054 [Opn-Nab]: Call-time pass-by-reference has been removed
Edit report at https://bugs.php.net/bug.php?id=65054edit=1 ID: 65054 Updated by: ras...@php.net Reported by:stefanmruk at yahoo dot co dot uk Summary:Call-time pass-by-reference has been removed -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: linux PHP Version:5.4.16 Block user comment: N Private report: N New Comment: Sorry, this is not a support forum. Previous Comments: [2013-06-18 03:46:33] stefanmruk at yahoo dot co dot uk Description: Why Test script: --- if ( method_exists( $obj, init ) ) if(PHP_VERSION_ID 5 ) $obj-init($this); else $obj-init($this); -- Edit this bug report at https://bugs.php.net/bug.php?id=65054edit=1
