Bug #54692 [Opn]: SQLite3::open() Return Value
Edit report at http://bugs.php.net/bug.php?id=54692edit=1
ID: 54692
Updated by: scott...@php.net
Reported by:ostico at gmail dot com
Summary:SQLite3::open() Return Value
Status: Open
Type: Bug
Package:SQLite related
Operating System: Ubuntu Server
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
documentation is wrong, it returns void always. Exception on error
Previous Comments:
[2011-05-08 23:14:13] ostico at gmail dot com
Description:
As the Php Reference said:
SQLite3::open
Returns TRUE on success, FALSE on failure to open the database.
But this IS NOT TRUE.
It Returns NULL.
Test script:
---
class testSQLite3 extends SQLite3{
public function __construct(){
var_dump( $this-open('test.sqlite3') );
}
}
new testSQLite3();
Expected result:
//Create File 'test.sqlite3' And
//output
//bool(true)
Actual result:
--
//Create File 'test.sqlite3' And
//output
//NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=54692edit=1
Bug #54674 [Asn-Csd]: mysqlnd valid_sjis_(head|tail) is using invalid operator and range.
Edit report at http://bugs.php.net/bug.php?id=54674edit=1
ID: 54674
Updated by: and...@php.net
Reported by:nihen at megabbs dot com
Summary:mysqlnd valid_sjis_(head|tail) is using invalid
operator and range.
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: All
PHP Version:5.3.6
Assigned To:mysql
Block user comment: N
Private report: N
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.
Range fixed in SVN. Thanks!
Previous Comments:
[2011-05-10 05:31:23] nihen at megabbs dot com
Thank you for operator fix.
but, it does not fix invalid range.
#define valid_sjis_tail(c) ((0x40 = (c) (c) = 0x7E) || (0x80 =
(c)
(c) = 0x7C))
to
#define valid_sjis_tail(c) ((0x40 = (c) (c) = 0x7E) || (0x80 =
(c) (c)
= 0xFC))
is correct.
s/7C/FC/
[2011-05-09 18:24:18] and...@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.
Thanks for the report!
[2011-05-09 18:20:37] and...@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=310856
Log: Fix for bug 54674..typo in the check of SJIS
[2011-05-06 12:11:17] nihen at megabbs dot com
Original report by Hiroshi Tokumaru.
http://www.tokumaru.org/d/20110322.html#p01
http://www.tokumaru.org/d/20110329.html#p01
(lang:japanese)
[2011-05-06 11:54:38] nihen at megabbs dot com
Description:
impacts to:
1. mysqli-real_escape_string
2. use PDO at PDO::ATTR_EMULATE_PREPARES = true
real_escape_string must not escape multi-byte character.
but escape it.
This bug is a SQL-injection may cause.
Test script:
---
?php
$japanese_so = pack('H4', '835c');
$mysql = mysqli_connect('localhost', 'sandbox', 'sandbox');
$mysql-set_charset('sjis');
echo $mysql-real_escape_string($japanese_so) === $japanese_so ? 'ok' :
'ng';
echo \n;
Expected result:
echo ok\n
Actual result:
--
echo ng\n
--
Edit this bug report at http://bugs.php.net/bug.php?id=54674edit=1
Bug #54421 [Opn-Fbk]: bindValue does not process utf-8 encoded strings.
Edit report at http://bugs.php.net/bug.php?id=54421edit=1
ID: 54421
Updated by: u...@php.net
Reported by:will dot skates at ntlworld dot com
Summary:bindValue does not process utf-8 encoded strings.
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: Found on win and linux(centos)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
What exactly does this mean: when set names is set as utf8 in both
execute and as one of the options in the PDO construct? Please, provide
complete test script including set names ... options in the PDO
construct.
Previous Comments:
[2011-03-30 01:30:20] will dot skates at ntlworld dot com
Description:
I'm currently developing a piece of software system for a Russian
client. When set names is set as utf8 in both execute and as one of the
options in the PDO construct, no results are returned when a utf8 string
is bound using bindValue();
Test script:
---
$stmt = $pdo-prepare('SELECT * FROM table WHERE column LIKE ?');
$stmt-bindValue(1,\'%пÑивеÑ%\');
$stmt-execute();
$result = $stmt-fetchAll(PDO::FETCH_ASSOC);
var_dump($result);
Expected result:
array(1) { column = пÑÐ¸Ð²ÐµÑ }
Actual result:
--
array(0){}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54421edit=1
Bug #54421 [Fbk]: bindValue does not process utf-8 encoded strings.
Edit report at http://bugs.php.net/bug.php?id=54421edit=1
ID: 54421
Updated by: u...@php.net
Reported by:will dot skates at ntlworld dot com
Summary:bindValue does not process utf-8 encoded strings.
Status: Feedback
Type: Bug
Package:PDO related
Operating System: Found on win and linux(centos)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
... and what database are you talking about. PDO works with many.
Previous Comments:
[2011-05-10 09:28:21] u...@php.net
What exactly does this mean: when set names is set as utf8 in both
execute and as one of the options in the PDO construct? Please, provide
complete test script including set names ... options in the PDO
construct.
[2011-03-30 01:30:20] will dot skates at ntlworld dot com
Description:
I'm currently developing a piece of software system for a Russian
client. When set names is set as utf8 in both execute and as one of the
options in the PDO construct, no results are returned when a utf8 string
is bound using bindValue();
Test script:
---
$stmt = $pdo-prepare('SELECT * FROM table WHERE column LIKE ?');
$stmt-bindValue(1,\'%пÑивеÑ%\');
$stmt-execute();
$result = $stmt-fetchAll(PDO::FETCH_ASSOC);
var_dump($result);
Expected result:
array(1) { column = пÑÐ¸Ð²ÐµÑ }
Actual result:
--
array(0){}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54421edit=1
[PHP-BUG] Bug #54700 [NEW]: PEAR won't compile extensions after PHP is compiled with CFLAGS
From: Operating system: Ubuntu 2.6.32-31-server 10.04.2 PHP version: Irrelevant Package: Compile Failure Bug Type: Bug Bug description:PEAR won't compile extensions after PHP is compiled with CFLAGS Description: I custom compiled PHP 5.3.4 with this command on my 64-bit Ubuntu 2.6.32-31-server 10.04.2 Server with the latest updates applied. I am trying to compile PHP to handle large files (2GB+). The installation goes well if I compile PHP without the CFLAGS. Also, the version of the PHP doesn't matter either--I have the same problem if I try to compile 5.2.11. [COMMANDS] cd /usr/local/src/; rm * -fR; cd /usr/local/src/;wget http://us.php.net/distributions/php-5.3.4.tar.gz;wget http://download.suhosin.org/suhosin-patch-5.3.4-0.9.10.patch.gz cd /usr/local/src/; rm php-5.3.4/ -fR; tar -xzf php-5.3.4.tar.gz; gunzip suhosin-patch-5.3.4-0.9.10.patch.gz; cd php-5.3.4/; patch -p 1 -i ../suhosin-patch-5.3.4-0.9.10.patch ;touch ac* ;./buildconf --force cd /usr/local/src/php-5.3.4/; CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ./configure --prefix=/usr --with-config-file-path=/etc/php5/cgi --with-config-file-scan-dir=/etc/php5/cgi/conf.d --mandir=/usr/share/man --disable-debug --disable-pdo --disable-rpath --disable-static --enable-bcmath --enable-calendar --enable-ctype --enable-dbx --enable-discard-path --enable-exif --enable-fastcgi --enable-filepro --enable-force-redirect --enable-ftp --enable-gd-native-ttf --enable-inline-optimization --enable-mbregex --enable-mbstring --enable-memcache --enable-memory-limit --enable-pcntl --enable-pic --enable-session --enable-shmop --enable-simplexml --enable-soap --enable-sockets --enable-suhosin --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-wddx --enable-xslt --enable-zip --with-bz2 --with-curl=shared,/usr --with-curlwrappers --with-exec-dir=/usr/lib/php5/libexec --with-freetype-dir=shared,/usr --with-gd=shared,/usr --with-gettext --with-gmp=shared,/usr --with-iconv --with-jpeg-dir=shared,/usr --with-kerberos=/usr --with-layout=GNU --with-libxml-dir=/usr --with-mcrypt --with-mhash=shared,/usr --with-mime-magic=/usr/share/file/magic.mime --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --with-openssl=/usr --without-gdbm --without-mm --without-pdo-sqlite --without-sqlite --with-pcre-regex=/usr --with-pear=/usr/share/php --with-pic --with-png-dir=shared,/usr --with-regex=php --with-system-tzdata --with-tidy=shared,/usr --with-ttf=shared,/usr --with-xml --with-xmlrpc=shared --with-xpm-dir=shared --with-xsl=shared,/usr --with-zlib;make; make install [/COMMANDS] I then issued these commands to install PHP extensions: [COMMANDS] pear update-channels;pecl uninstall apc;pecl install apc;pear upgrade PEAR; pear install HTTP; pear install HTTP_Download; pear install HTTP_Header; pear install MIME_Type; pecl install pecl_http [/COMMANDS] OUTPUT: root@web1:/usr# pear update-channels;pecl uninstall apc;pecl install apc;pear upgrade PEAR; pear install HTTP; pear install HTTP_Download; pear install HTTP_Header; pear install MIME_Type; pecl install pecl_http Updating channel doc.php.net Channel doc.php.net is up to date Updating channel pear.php.net Channel pear.php.net is up to date Updating channel pecl.php.net Channel pecl.php.net is up to date pecl/apc not installed downloading APC-3.1.6.tgz ... Starting to download APC-3.1.6.tgz (148,835 bytes) .done: 148,835 bytes downloading PEAR-1.9.2.tgz ... Starting to download PEAR-1.9.2.tgz (295,120 bytes) .done: 295,120 bytes downloading HTTP-1.4.1.tgz ... Starting to download HTTP-1.4.1.tgz (8,635 bytes) .done: 8,635 bytes Did not download optional dependencies: pear/Archive_Zip, pear/MIME_Type, use --alldeps to download automatically pear/HTTP_Download can optionally use package pear/Archive_Zip pear/HTTP_Download can optionally use package pear/MIME_Type pear/HTTP_Download can optionally use PHP extension mime_magic pear/HTTP_Download can optionally use PHP extension pgsql downloading HTTP_Download-1.1.4.tgz ... Starting to download HTTP_Download-1.1.4.tgz (14,571 bytes) .done: 14,571 bytes downloading HTTP_Header-1.2.1.tgz ... Starting to download HTTP_Header-1.2.1.tgz (10,682 bytes) .done: 10,682 bytes Did not download optional dependencies: pear/System_Command, use --alldeps to download automatically pear/MIME_Type can optionally use package pear/System_Command downloading MIME_Type-1.2.1.tgz ... Starting to download MIME_Type-1.2.1.tgz (11,609 bytes) .done: 11,609 bytes downloading pecl_http-1.7.0.tgz ... Starting to download pecl_http-1.7.0.tgz (173,979 bytes) .done: 173,979 bytes root@web1:/usr# Test script: --- Please see above in the Description field.
Bug #54258 [Opn-Fbk]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
Edit report at http://bugs.php.net/bug.php?id=54258edit=1 ID: 54258 Updated by: u...@php.net Reported by:an0nym at narod dot ru Summary:MySQL: Silent ignorance of binds inside comments causes other to be wrong bound -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Can't reproduce. Please, provide full example including connect, create table, error handling and so forth. Previous Comments: [2011-03-15 16:30:52] an0nym at narod dot ru Description: See test script. Test script: --- $statement = $DB-prepare(UPDATE t SET /*field1 = :field1, */field2 = :field2); $field1 = 1; $field2 = 2; $statement-bindParam(:field1, $field1, PDO::PARAM_INT); $statement-bindParam(:field2, $field2, PDO::PARAM_INT); $statement-execute(); Expected result: Query UPDATE t SET /*field1 = 1, */field2 = 2 or error message like wrong param count. Actual result: -- Silently running query UPDATE t SET /*field1 = ?, */field2 = 1. -- Edit this bug report at http://bugs.php.net/bug.php?id=54258edit=1
Bug #53960 [Opn-Bgs]: Invalid parameter number for multiple params equals in query
Edit report at http://bugs.php.net/bug.php?id=53960edit=1
ID: 53960
Updated by: u...@php.net
Reported by:contato at andersonfraga dot net
Summary:Invalid parameter number for multiple params
equals in query
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: Windows
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
SQL - 2x hash_1:
AND (NOME_CLIENTE LIKE :hash_1
OR ENDERECO_CLIENTE LIKE :hash_1)
PHP bind - 1x hash_1, 1x hash_2:
$statement-execute(Array(
':hash_1' = '%Anderson%',
':hash_2' = 0,
Previous Comments:
[2011-02-08 17:27:49] contato at andersonfraga dot net
Description:
This error is occurring when I use the same parameter several times in
the query.
In PHP 5.2.14, using Gentoo, it works perfectly. Already in versions
5.3.0 and 5.3.3 (using Windows on both), returns an exception.
Bug or 'feature'?
Test script:
---
?php
try {
$dbh = new PDO('mysql:/*irrelevant*/', Array(
PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
));
$select = SELECT * FROM PR_CLIENTE
WHERE DELETADO = 'N'
AND (NOME_CLIENTE LIKE :hash_1
OR ENDERECO_CLIENTE LIKE :hash_1)
ORDER BY ID_CLIENTE DESC
LIMIT :hash_2;;
$statement = $dbh-prepare($select);
$statement-execute(Array(
':hash_1' = '%Anderson%',
':hash_2' = 0,
));
$fetch = $statement-fetchAll(PDO::FETCH_ASSOC);
print_r($fetch);
}
catch(PDOException $e) {
print_r($e-getMessage());
}
?
Expected result:
Array
(
[0] = Array
(
[ID_CLIENTE] = 29
(...)
)
)
Actual result:
--
SQLSTATE[HY093]: Invalid parameter number
--
Edit this bug report at http://bugs.php.net/bug.php?id=53960edit=1
Bug #53782 [Opn-Bgs]: foreach throws irrelevant exception
Edit report at http://bugs.php.net/bug.php?id=53782edit=1
ID: 53782
Updated by: u...@php.net
Reported by:david at grudl dot com
Summary:foreach throws irrelevant exception
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Running errenous query and not expecting exception is bogus.
Previous Comments:
[2011-01-18 21:30:47] david at grudl dot com
Description:
Iteration using foreach throws previous and irrelevant exception.
Exception is throwed after last iteration.
Test script:
---
$conn = new PDO(mysql:dbname=test);
$conn-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $conn-query('SELECT * FROM categories');
try {
$conn-query('ERROR');
} catch (PDOException $e) { // exception is catched
}
foreach ($res as $k = $v); // now is throwed exception $e !!!
Expected result:
do nothing
--
Edit this bug report at http://bugs.php.net/bug.php?id=53782edit=1
Bug #54692 [Opn-Asn]: SQLite3::open() Return Value
Edit report at http://bugs.php.net/bug.php?id=54692edit=1
ID: 54692
Updated by: ahar...@php.net
Reported by:ostico at gmail dot com
Summary:SQLite3::open() Return Value
-Status: Open
+Status: Assigned
Type: Bug
Package:SQLite related
Operating System: Ubuntu Server
PHP Version:Irrelevant
-Assigned To:
+Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
Looks like the prototype comments are wrong in the actual source, too.
Previous Comments:
[2011-05-10 08:51:06] scott...@php.net
documentation is wrong, it returns void always. Exception on error
[2011-05-08 23:14:13] ostico at gmail dot com
Description:
As the Php Reference said:
SQLite3::open
Returns TRUE on success, FALSE on failure to open the database.
But this IS NOT TRUE.
It Returns NULL.
Test script:
---
class testSQLite3 extends SQLite3{
public function __construct(){
var_dump( $this-open('test.sqlite3') );
}
}
new testSQLite3();
Expected result:
//Create File 'test.sqlite3' And
//output
//bool(true)
Actual result:
--
//Create File 'test.sqlite3' And
//output
//NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=54692edit=1
Bug #54583 [Opn-Fbk]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583edit=1
ID: 54583
Updated by: u...@php.net
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Which version of libmysql is used, what's the server version?
Previous Comments:
[2011-04-22 17:23:13] an0nym at narod dot ru
Everything works fine with php5.3.5 + mysqlnd @ winsrv2008r2x64. So it
seems that
the error is with libmysql only.
[2011-04-21 11:56:55] an0nym at narod dot ru
Try new test code, please. I will submit backtrace when I manage to
generate it.
[2011-04-21 11:54:42] an0nym at narod dot ru
It seems you don't have strict mode enabled.
Try this.
?php
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
PDO::MYSQL_ATTR_INIT_COMMAND = SET SQL_MODE =
'STRICT_ALL_TABLES'));
$DB-exec(CREATE TEMPORARY TABLE t(f VARCHAR(1)));
$stmt = $DB-prepare(INSERT INTO t VALUES(:value));
$value = aa;
$stmt-bindParam(:value, $value);
try {
$stmt-execute();
} catch (PDOException $e) {}
$stmt-execute();
[2011-04-21 11:28:22] johan...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Works for me with libmysql and mysqlnd. Please provide a stacktrace and
the version of libmysql you are using.
[2011-04-21 08:29:44] an0nym at narod dot ru
There was a similar problem that was patched in PHP 5.3.6.
http://bugs.php.net/53551
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=54583
--
Edit this bug report at http://bugs.php.net/bug.php?id=54583edit=1
Req #54698 [Opn-Wfx]: setAttribute
Edit report at http://bugs.php.net/bug.php?id=54698edit=1
ID: 54698
Updated by: ahar...@php.net
Reported by:broshizzledizzle at gmail dot com
Summary:setAttribute
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:DOM XML related
Operating System: (irrelevant)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Given how widely the DOM extension is used, I don't think it would be
a good idea to break backward compatibility now, even in a good cause.
Closing won't fix.
Previous Comments:
[2011-05-10 00:15:28] broshizzledizzle at gmail dot com
Description:
It makes more sense for setAttribute() to return the object it was
called on
instead of the attribute that was set. If I was interested in the
attribute, I'd
have use createAttribute() instead.
Test script:
---
$dom = new DOMDocument();
$body = $dom-createElement('body');
$dom-appendChild($body-setAttribute('class', 'wrapper'));
echo $dom-saveHTML();
Expected result:
I would expect that it would properly append $body to the $dom.
Actual result:
--
Warning: DOMNode::appendChild() [domnode.appendchild]: Couldn't append
node in
_FILE_ on _LINE_.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54698edit=1
Req #54698 [Com]: setAttribute
Edit report at http://bugs.php.net/bug.php?id=54698edit=1
ID: 54698
Comment by: broshizzledizzle at gmail dot com
Reported by:broshizzledizzle at gmail dot com
Summary:setAttribute
Status: Wont fix
Type: Feature/Change Request
Package:DOM XML related
Operating System: (irrelevant)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I understood the implication of what I suggested when I posted. This
exact same
flaw happens in so many methods of the DOM that I always have to look up
return
values to see what actually gets returned, rather than what would be
useful.
I'm not looking to get into a fight, but think about what you said: I
don't
think it would be
a good idea to break backward compatibility now, even in a good cause.
Doesn't
that grate on your nerves? You are saying, we won't right the wrong we
made in
the beginning because a lot of people use this extension. Ever heard of
investing in your future? I don't think PHP is going to die anytime
soon, and if
we're going to ever improve the DOM in this regard we'll probably never
have a
better time. It'll just get harder the longer we wait.
Previous Comments:
[2011-05-10 10:17:16] ahar...@php.net
Given how widely the DOM extension is used, I don't think it would be
a good idea to break backward compatibility now, even in a good cause.
Closing won't fix.
[2011-05-10 00:15:28] broshizzledizzle at gmail dot com
Description:
It makes more sense for setAttribute() to return the object it was
called on
instead of the attribute that was set. If I was interested in the
attribute, I'd
have use createAttribute() instead.
Test script:
---
$dom = new DOMDocument();
$body = $dom-createElement('body');
$dom-appendChild($body-setAttribute('class', 'wrapper'));
echo $dom-saveHTML();
Expected result:
I would expect that it would properly append $body to the $dom.
Actual result:
--
Warning: DOMNode::appendChild() [domnode.appendchild]: Couldn't append
node in
_FILE_ on _LINE_.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54698edit=1
Bug #54692 [Asn-Csd]: SQLite3::open() Return Value
Edit report at http://bugs.php.net/bug.php?id=54692edit=1
ID: 54692
Updated by: ahar...@php.net
Reported by:ostico at gmail dot com
Summary:SQLite3::open() Return Value
-Status: Assigned
+Status: Closed
Type: Bug
Package:SQLite related
Operating System: Ubuntu Server
PHP Version:Irrelevant
Assigned To:aharvey
Block user comment: N
Private report: N
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.
Documentation and source updated.
Previous Comments:
[2011-05-10 10:14:57] ahar...@php.net
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=310877
Log: Fix bug #54692 (SQLite3::open() Return Value) by correcting the
SQLite3::open()
prototype.
[2011-05-10 10:10:54] ahar...@php.net
Looks like the prototype comments are wrong in the actual source, too.
[2011-05-10 08:51:06] scott...@php.net
documentation is wrong, it returns void always. Exception on error
[2011-05-08 23:14:13] ostico at gmail dot com
Description:
As the Php Reference said:
SQLite3::open
Returns TRUE on success, FALSE on failure to open the database.
But this IS NOT TRUE.
It Returns NULL.
Test script:
---
class testSQLite3 extends SQLite3{
public function __construct(){
var_dump( $this-open('test.sqlite3') );
}
}
new testSQLite3();
Expected result:
//Create File 'test.sqlite3' And
//output
//bool(true)
Actual result:
--
//Create File 'test.sqlite3' And
//output
//NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=54692edit=1
Req #54698 [Wfx]: setAttribute
Edit report at http://bugs.php.net/bug.php?id=54698edit=1
ID: 54698
Updated by: ras...@php.net
Reported by:broshizzledizzle at gmail dot com
Summary:setAttribute
Status: Wont fix
Type: Feature/Change Request
Package:DOM XML related
Operating System: (irrelevant)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think if we were to fix it, we would make it return void or false on
an error
to comply better with the DOM spec. Changing it from one value that
doesn't
comply with the spec to another one that also doesn't comply doesn't
make much
sense.
Previous Comments:
[2011-05-10 10:35:57] broshizzledizzle at gmail dot com
I understood the implication of what I suggested when I posted. This
exact same
flaw happens in so many methods of the DOM that I always have to look up
return
values to see what actually gets returned, rather than what would be
useful.
I'm not looking to get into a fight, but think about what you said: I
don't
think it would be
a good idea to break backward compatibility now, even in a good cause.
Doesn't
that grate on your nerves? You are saying, we won't right the wrong we
made in
the beginning because a lot of people use this extension. Ever heard of
investing in your future? I don't think PHP is going to die anytime
soon, and if
we're going to ever improve the DOM in this regard we'll probably never
have a
better time. It'll just get harder the longer we wait.
[2011-05-10 10:17:16] ahar...@php.net
Given how widely the DOM extension is used, I don't think it would be
a good idea to break backward compatibility now, even in a good cause.
Closing won't fix.
[2011-05-10 00:15:28] broshizzledizzle at gmail dot com
Description:
It makes more sense for setAttribute() to return the object it was
called on
instead of the attribute that was set. If I was interested in the
attribute, I'd
have use createAttribute() instead.
Test script:
---
$dom = new DOMDocument();
$body = $dom-createElement('body');
$dom-appendChild($body-setAttribute('class', 'wrapper'));
echo $dom-saveHTML();
Expected result:
I would expect that it would properly append $body to the $dom.
Actual result:
--
Warning: DOMNode::appendChild() [domnode.appendchild]: Couldn't append
node in
_FILE_ on _LINE_.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54698edit=1
Bug #54444 [Com]: Multiple Queries on a single conenction
Edit report at http://bugs.php.net/bug.php?id=5edit=1
ID: 5
Comment by: peter dot colclough at toolstation dot com
Reported by:peter dot colclough at toolstation dot com
Summary:Multiple Queries on a single conenction
Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: Ubuntu 10 64 bit
PHP Version:5.3SVN-2011-04-01 (SVN)
Block user comment: N
Private report: N
New Comment:
True... but it doesn't do this ($conn is a connection) ... and don't
copy this code.. its not good.. but gets the point across:
$basesql = 'SELECT SQL_NO_CACHE id from table1 ';
$baseqry = bmysqli_query($basesql, $conn);
$qry = bmysqli_query('Select SQL_NO_CACHE * from table2 where id2 = ?
',$conn);
$qry1 = bmysqli_query('Select SQL_NO_CACHE * from table3 where id3 = ?
',$conn);
$qry2 = bmysqli_query('Select SQL_NO_CACHE * from table4 where id4 = ?
',$conn);
while(TRUE){
$nBaseRes = bmysqli_fetch($baseqry);
if(empty($nBaseRes)){
break;
}
$aId = array(0 =$nBaseRes['id']);
// The first bound query
bmysqli_execute($qry, $aId);
$nRes = bmysqli_fetch($qry);
$aVals = array(0=$nRes['id2']);
bmysqli_execute($qry1, $aVals);
while(TRUE){// careful Peter
$nRes1 = bmysqli_fetch($qry1);
if(empty($nRes1)){
break;
}
$aItems = array(0 = $nRes1['id3']);
bmysqli_execute($qry2, $aItems);
while(TRUE){// careful Peter
$nRes2 = bmysqli_fetch($qry2);
if(empty($nRes2)){
break;
}
}
}
Previous Comments:
[2011-05-09 17:00:40] u...@php.net
Hmm, you can prepare as many statements as you want per connection. But
once you have executed a statement on a connection you must fetch its
results before you can execute another statement. The result set
blocks the line.
You can, of course, do an implicit fetch on the C level upon execute but
that's the exact opposite of the default fetch method (unbuffered) used
for prepared statements by MySQL.
Its a one-liner to do that fetch in user land. No need for changes on
the C level.
$mysqli = new mysqli(localhost, root, root, test);
$stmt1 = $mysqli-prepare(SELECT 1 AS _one FROM DUAL);
$stmt2 = $mysqli-prepare(SELECT 2 AS _two FROM DUAL);
/* execute */
if (!$stmt1-execute())
printf([001] [%d] %s\n, $stmt1-errno, $stmt1-error);
/* clear line by fetching result set */
$res1 = $stmt1-get_result();
/* execute */
if (!$stmt2-execute())
printf([002] [%d] %s\n, $stmt2-errno, $stmt2-error);
/* clear line by fetching result set */
$res2 = $stmt2-get_result();
/* fetching second first */
while ($row = $res2-fetch_assoc())
var_dump($row);
$res2-free();
while ($row = $res1-fetch_assoc())
var_dump($row);
$res1-free();
[2011-05-09 16:35:37] peter dot colclough at toolstation dot com
Thanks for teh feedback. I was also getting that error, just wanted to
make sure it wasn't 'me'... but actually expected behaviour.
Am now devbeloping my own, that allows multiple statements per
connection, as well as multiple 'prepare' statements. This will be open
sourced when ready.
The current mysqli interface should have been able to do this, but it
was obviously decided not to allow it... which is a bit of a pain.
Thanks again for your input
[2011-05-09 16:14:45] u...@php.net
You can answer this question yourself by adding a bit of error handling
to your script such as ...
$mysqli = new mysqli(localhost, root, root, test);
$stmt1 = $mysqli-prepare(SELECT 1 AS _one FROM DUAL);
$stmt2 = $mysqli-prepare(SELECT 2 AS _two FROM DUAL);
if (!$stmt1-execute() || !($meta1 = $stmt2-result_metadata()))
printf([001] [%d] %s\n, $stmt1-errno, $stmt1-error);
if (!$stmt2-execute() || !($meta2 = $stmt2-result_metadata()))
printf([002] [%d] %s\n, $stmt2-errno, $stmt2-error);
... and the answer is:
[002] [2014] Commands out of sync; you can't run this command now
[2011-04-01 16:13:48] peter dot colclough at toolstation dot com
Description:
Hi, trying to build a generic DB object handler for mySqli, and have hit
an issue where we can't have more than one open query on the same
connection. Is this a bug or 'expected behaviour'?
Looking at the mysqli.c source code, it looks like it should have been
possible, but it looks like the second object overwrites the first...
I have put a sample snippet below
Bug #32338 [Com]: 'UTF-8' badly supported by html_entity_decode ()
Edit report at http://bugs.php.net/bug.php?id=32338edit=1 ID: 32338 Comment by: xcoureau at ekino dot com Reported by:webmaster at reddi dot de Summary:'UTF-8' badly supported by html_entity_decode () Status: No Feedback Type: Bug Package:Strings related Operating System: Linux infong 2.4 PHP Version:5.0.3 Block user comment: N Private report: N New Comment: Bug still existing. Tested using 5.3.6 and 5.3.3-7 Previous Comments: [2005-03-25 01:47:13] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2005-03-18 19:22:56] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-03-16 16:17:21] webmaster at reddi dot de Description: Where html_entity_decode ( 'fnof;', ENT_NOQUOTES, 'ISO-8859-1') yields the expected result, html_entity_decode ( 'fnof;', ENT_NOQUOTES, 'UTF-8') does NOT. Reproduce code: --- ?= html_entity_decode ( 'fnof;', ENT_NOQUOTES, 'UTF-8') ; ? Expected result: /* which is 402 0192LATIN SMALL LETTER F WITH HOOK (entity name is fnof;) */ Actual result: -- #400; /* which is 400 0190LATIN CAPITAL LETTER OPEN E */ -- Edit this bug report at http://bugs.php.net/bug.php?id=32338edit=1
Bug #54583 [Fbk-Opn]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583edit=1
ID: 54583
User updated by:an0nym at narod dot ru
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
-Status: Feedback
+Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, CentOS is with mysqlnd now. Testing on Fedora:
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:32:59 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:33:02 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:33:06 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
PDO::MYSQL_ATTR_INIT_COMMAND = SET SQL_MODE =
'STRICT_ALL_TABLES'));
$DB-exec(CREATE TEMPORARY TABLE t(f VARCHAR(1)));
$stmt = $DB-prepare(INSERT INTO t VALUES(:value));
$value = aa;
$stmt-bindParam(:value, $value);
try {
$stmt-execute();
} catch (PDOException $e) {}
$stmt-execute();
06:33:17 ~
root@test # php test.php
bool(false)
Segmentation fault
06:33:24 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:34:43 ~
root@test #
Previous Comments:
[2011-05-10 10:15:36] u...@php.net
Which version of libmysql is used, what's the server version?
[2011-04-22 17:23:13] an0nym at narod dot ru
Everything works fine with php5.3.5 + mysqlnd @ winsrv2008r2x64. So it
seems that
the error is with libmysql only.
[2011-04-21 11:56:55] an0nym at narod dot ru
Try new test code, please. I will submit backtrace when I manage to
generate it.
[2011-04-21 11:54:42] an0nym at narod dot ru
It seems you don't have strict mode enabled.
Try this.
?php
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
PDO::MYSQL_ATTR_INIT_COMMAND = SET SQL_MODE =
'STRICT_ALL_TABLES'));
$DB-exec(CREATE TEMPORARY TABLE t(f VARCHAR(1)));
$stmt = $DB-prepare(INSERT INTO t VALUES(:value));
$value = aa;
$stmt-bindParam(:value, $value);
try {
$stmt-execute();
} catch (PDOException $e) {}
$stmt-execute();
[2011-04-21 11:28:22] johan...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Works for me with libmysql and mysqlnd. Please provide a stacktrace and
the version of libmysql you are using.
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=54583
--
Edit this bug report at http://bugs.php.net/bug.php?id=54583edit=1
Bug #54258 [Fbk-Opn]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
Edit report at http://bugs.php.net/bug.php?id=54258edit=1
ID: 54258
User updated by:an0nym at narod dot ru
Reported by:an0nym at narod dot ru
Summary:MySQL: Silent ignorance of binds inside comments
causes other to be wrong bound
-Status: Feedback
+Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:53:51 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:53:56 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:54:02 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false));
$DB-exec(CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1)) SELECT
0 f1, 0 f2);
$stmt = $DB-prepare(UPDATE t SET /*f1 = :field1, */f2 = :field2);
$field1 = 1;
$field2 = 2;
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
$stmt-execute();
foreach ($DB-query(SELECT * FROM t) as $row)
var_dump($row);
06:54:07 ~
root@test # php test.php
bool(false)
array(4) {
[f1]=
string(1) 0
[0]=
string(1) 0
[f2]=
string(1) 1
[1]=
string(1) 1
}
06:54:11 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:54:47 ~
root@test #
Previous Comments:
[2011-05-10 09:56:54] u...@php.net
Can't reproduce. Please, provide full example including connect, create
table, error handling and so forth.
[2011-03-15 16:30:52] an0nym at narod dot ru
Description:
See test script.
Test script:
---
$statement = $DB-prepare(UPDATE t SET /*field1 = :field1, */field2 =
:field2);
$field1 = 1;
$field2 = 2;
$statement-bindParam(:field1, $field1, PDO::PARAM_INT);
$statement-bindParam(:field2, $field2, PDO::PARAM_INT);
$statement-execute();
Expected result:
Query UPDATE t SET /*field1 = 1, */field2 = 2 or error message like
wrong param count.
Actual result:
--
Silently running query UPDATE t SET /*field1 = ?, */field2 = 1.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54258edit=1
Bug #54258 [Opn]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
Edit report at http://bugs.php.net/bug.php?id=54258edit=1
ID: 54258
User updated by:an0nym at narod dot ru
Reported by:an0nym at narod dot ru
Summary:MySQL: Silent ignorance of binds inside comments
causes other to be wrong bound
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
As you can see f2 is silently updated to 1 instead of exception (at
least) or right value 2.
Previous Comments:
[2011-05-10 12:55:23] an0nym at narod dot ru
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:53:51 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:53:56 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:54:02 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false));
$DB-exec(CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1)) SELECT
0 f1, 0 f2);
$stmt = $DB-prepare(UPDATE t SET /*f1 = :field1, */f2 = :field2);
$field1 = 1;
$field2 = 2;
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
$stmt-execute();
foreach ($DB-query(SELECT * FROM t) as $row)
var_dump($row);
06:54:07 ~
root@test # php test.php
bool(false)
array(4) {
[f1]=
string(1) 0
[0]=
string(1) 0
[f2]=
string(1) 1
[1]=
string(1) 1
}
06:54:11 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:54:47 ~
root@test #
[2011-05-10 09:56:54] u...@php.net
Can't reproduce. Please, provide full example including connect, create
table, error handling and so forth.
[2011-03-15 16:30:52] an0nym at narod dot ru
Description:
See test script.
Test script:
---
$statement = $DB-prepare(UPDATE t SET /*field1 = :field1, */field2 =
:field2);
$field1 = 1;
$field2 = 2;
$statement-bindParam(:field1, $field1, PDO::PARAM_INT);
$statement-bindParam(:field2, $field2, PDO::PARAM_INT);
$statement-execute();
Expected result:
Query UPDATE t SET /*field1 = 1, */field2 = 2 or error message like
wrong param count.
Actual result:
--
Silently running query UPDATE t SET /*field1 = ?, */field2 = 1.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54258edit=1
Bug #54583 [Opn]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583edit=1
ID: 54583
Updated by: u...@php.net
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
Affects libmysql only. No issue when using mysqlnd.
Johannes, please review and apply patch:
nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_3 svn diff
ext/pdo_mysql/
Index: ext/pdo_mysql/mysql_statement.c
===
--- ext/pdo_mysql/mysql_statement.c (Revision 310880)
+++ ext/pdo_mysql/mysql_statement.c (Arbeitskopie)
@@ -136,6 +136,7 @@
{
pdo_mysql_stmt *S = stmt-driver_data;
pdo_mysql_db_handle *H = S-H;
+ int paramno;
PDO_DBG_ENTER(pdo_mysql_stmt_execute_prepared_libmysql);
@@ -143,6 +144,10 @@
if (mysql_stmt_bind_param(S-stmt, S-params) ||
mysql_stmt_execute(S-stmt)) {
if (S-params) {
memset(S-params, 0, S-num_params *
sizeof(MYSQL_BIND));
+ for (paramno = 0; paramno S-num_params;
paramno++) {
+ S-params[paramno].is_null =
S-in_null[paramno];
+ S-params[paramno].length =
S-in_length[paramno];
+ }
}
pdo_mysql_error_stmt(stmt);
if (mysql_stmt_errno(S-stmt) == 2057) {
Previous Comments:
[2011-05-10 12:36:54] an0nym at narod dot ru
Sorry, CentOS is with mysqlnd now. Testing on Fedora:
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:32:59 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:33:02 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:33:06 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
PDO::MYSQL_ATTR_INIT_COMMAND = SET SQL_MODE =
'STRICT_ALL_TABLES'));
$DB-exec(CREATE TEMPORARY TABLE t(f VARCHAR(1)));
$stmt = $DB-prepare(INSERT INTO t VALUES(:value));
$value = aa;
$stmt-bindParam(:value, $value);
try {
$stmt-execute();
} catch (PDOException $e) {}
$stmt-execute();
06:33:17 ~
root@test # php test.php
bool(false)
Segmentation fault
06:33:24 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:34:43 ~
root@test #
[2011-05-10 10:15:36] u...@php.net
Which version of libmysql is used, what's the server version?
[2011-04-22 17:23:13] an0nym at narod dot ru
Everything works fine with php5.3.5 + mysqlnd @ winsrv2008r2x64. So it
seems that
the error is with libmysql only.
[2011-04-21 11:56:55] an0nym at narod dot ru
Try new test code, please. I will submit backtrace when I manage to
generate it.
[2011-04-21 11:54:42] an0nym at narod dot ru
It seems you don't have strict mode enabled.
Try this.
?php
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
PDO::MYSQL_ATTR_INIT_COMMAND = SET SQL_MODE =
'STRICT_ALL_TABLES'));
$DB-exec(CREATE TEMPORARY TABLE t(f VARCHAR(1)));
$stmt = $DB-prepare(INSERT INTO t VALUES(:value));
$value = aa;
$stmt-bindParam(:value, $value);
try {
$stmt-execute();
} catch (PDOException $e) {}
$stmt-execute();
The remainder of the comments for this
Bug #54421 [Fbk-Csd]: bindValue does not process utf-8 encoded strings.
Edit report at http://bugs.php.net/bug.php?id=54421edit=1
ID: 54421
User updated by:will dot skates at ntlworld dot com
Reported by:will dot skates at ntlworld dot com
Summary:bindValue does not process utf-8 encoded strings.
-Status: Feedback
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Found on win and linux(centos)
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Please have my sincere apologies, this issue has been resolved. I'll
file a fix soon.
Previous Comments:
[2011-05-10 09:28:50] u...@php.net
... and what database are you talking about. PDO works with many.
[2011-05-10 09:28:21] u...@php.net
What exactly does this mean: when set names is set as utf8 in both
execute and as one of the options in the PDO construct? Please, provide
complete test script including set names ... options in the PDO
construct.
[2011-03-30 01:30:20] will dot skates at ntlworld dot com
Description:
I'm currently developing a piece of software system for a Russian
client. When set names is set as utf8 in both execute and as one of the
options in the PDO construct, no results are returned when a utf8 string
is bound using bindValue();
Test script:
---
$stmt = $pdo-prepare('SELECT * FROM table WHERE column LIKE ?');
$stmt-bindValue(1,\'%пÑивеÑ%\');
$stmt-execute();
$result = $stmt-fetchAll(PDO::FETCH_ASSOC);
var_dump($result);
Expected result:
array(1) { column = пÑÐ¸Ð²ÐµÑ }
Actual result:
--
array(0){}
--
Edit this bug report at http://bugs.php.net/bug.php?id=54421edit=1
Bug #53782 [Bgs]: foreach throws irrelevant exception
Edit report at http://bugs.php.net/bug.php?id=53782edit=1
ID: 53782
User updated by:david at grudl dot com
Reported by:david at grudl dot com
Summary:foreach throws irrelevant exception
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This is a serious bug in the PDO. Look at the example more closely.
Variable $res has nothing to do with errenous query.
Previous Comments:
[2011-05-10 10:06:47] u...@php.net
Running errenous query and not expecting exception is bogus.
[2011-01-18 21:30:47] david at grudl dot com
Description:
Iteration using foreach throws previous and irrelevant exception.
Exception is throwed after last iteration.
Test script:
---
$conn = new PDO(mysql:dbname=test);
$conn-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $conn-query('SELECT * FROM categories');
try {
$conn-query('ERROR');
} catch (PDOException $e) { // exception is catched
}
foreach ($res as $k = $v); // now is throwed exception $e !!!
Expected result:
do nothing
--
Edit this bug report at http://bugs.php.net/bug.php?id=53782edit=1
Bug #52624 [Com]: tempnam() in SAFE Mode
Edit report at http://bugs.php.net/bug.php?id=52624edit=1
ID: 52624
Comment by: alexis dot olivier at unicaen dot fr
Reported by:hirad dot navid at t-systems dot at
Summary:tempnam() in SAFE Mode
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: RHEL 5
PHP Version:5.2.14
Block user comment: N
Private report: N
New Comment:
Hello everybody,
We got the same case with open_basedir restriction.
The users have no access to /tmp (they have their own tmp dir). When
calling tempnam('/tmp', 'tempname'), The open_basedir restriction takes
effect and creation of the file is forbidden.
But, when calling tempnam('path_that_doesnt_exist', 'tempname'), the
function takes /tmp in fallback and file is created (overriding the
open_basedir restriction). The file can't be written (open_basedir
restriction), but this bug can be used to overflow tmp directory.
I think it lacks a test in the function to protect from writing out of
open_basedir restriction.
Test script:
With open_basedir not including /tmp :
?php
// This gives a warning
echo tempnam(/tmp, prefix_);
// This creates a file in /tmp
echo tempnam(directory_that_not_exists, prefix_);
?
Previous Comments:
[2010-08-17 14:39:52] hirad dot navid at t-systems dot at
Description:
Dear php Team,
We are using php 5.2.13 and Safe_mod is ON.
we have a problem using tempnam, at first we had tempnam('',tempfile);
This did not work - error can not access /tmp
Later I investigated and have written the testscript and have following
behavior. Attention script must be owned by non root user
the script with 7th line $tmp_name = tempnam ( 'tmp', 'tempname' );
works fine also with safe_mode
when i change it to $tmp_name = tempnam ( '/tmp', 'tempname' ); a
safe_mode restriction takes effect (the one with compares UID/GID and
puts out
Warning: tempnam() [function.tempnam]: SAFE MODE Restriction in effect.
The script whose uid/gid is 506/506 is not allowed to access /tmp owned
by uid/gid 0/0 in /home/httpd/html/default/tempfile.php on line 7
but why does it work without the beginning '/'?
Can you clarify this behavior please? and another issuse is that when i
try with $tmp_name = tempnam ( '/tmp', 'tempname' ); it does not make a
diference putting /tmp to openbasedir or safe_mode_includedir it dies
not work.
I have also read the changelog and have found that since PHP 5.2.12 some
issues with tempname and safe_mode have been fixed - there was a bug
that tempnam ignores safe_mode. And this correct because i tested with
php 5.2.11 and it worked with /tmp also. Can you tell me ehat exactly is
changed saince version 5.2.12?
Test script:
---
?PHP
$xx = sys_get_temp_dir();
echo $xx . 'br';
for ( $x = 0; $x = 5; $x++ )
{
$tmp_name = tempnam ( 'tmp', 'tempname' );
echo $tmp_name . 'br';
}
$str = 'standing in a tempfile';
$tmp_file = fopen ( $tmp_name, 'w' );
fputs ( $tmp_file, $str );
fclose ( $tmp_file );
$fp = fopen ( $tmp_name, 'r' );
$str = fgets ( $fp, 50 );
fclose ( $fp );
echo $str;
?
Expected result:
script above works fine also in safe mode change 7th line from
$tmp_name = tempnam ( 'tmp', 'tempname' );
to
$tmp_name = tempnam ( '/tmp', 'tempname' ); bringe a safe_mode
restriction which is also ok, but why does it work without / and why
does it not make a diference putting /tmp to openbasedir or
safe_mode_include_dir
--
Edit this bug report at http://bugs.php.net/bug.php?id=52624edit=1
Bug #54646 [Opn-Fbk]: segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54646edit=1 ID: 54646 Updated by: u...@php.net Reported by:public at grik dot net Summary:segmentation fault -Status: Open +Status: Feedback Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Glad to hear mysqlnd works fine. Its impossible to tell what could be going on with libmysql by just checking the backtrace. You seem to be using an older version of MySQL/libmysql. Could you try a recent version of libmysql? Also, as hard as it is, it would be most helpful to get a reproducible test script. Previous Comments: [2011-05-01 21:14:07] public at grik dot net Sorry, I meant backtrace. Or you need some other one? [2011-05-01 21:06:41] public at grik dot net I am sorry, but the bugtrace is already posted in the report. [2011-05-01 14:27:55] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2011-05-01 14:26:47] public at grik dot net Description: I observe a segfault when running a xenforo package in debug mode. The configuration of the server is Fedora Core 8, MySQL 5.0.45 I recompiled PHP with debug mode and turned off all extensions not from the standard archive. I found a way to avoid it by recompiling the mysqli extension with mysqlnd driver. I am not really sure if it was worth to open this report as I don't know how you can reproduce it, but at least you'll hear about the issue. Test script: --- I am not sure I can make a minimal reproducable case. Xenforo is a large package based on Zend Framework. any call to the xenforo scripts in debug mode crashes php, both fcgi and cli Actual result: -- backtrace: Core was generated by `php index.php'. Program terminated with signal 11, Segmentation fault. #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 catalog, key_len=8, str=0x665f696b Address 0x665f696b out of bounds, duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 1524 ZVAL_STRING(tmp, str, duplicate); (gdb) bt #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 catalog, key_len=8, str=0x665f696b Address 0x665f696b out of bounds, duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 #1 0x00799f0c in php_add_field_properties (value=0xa62c714, field=0xa2aea28) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1056 #2 0x0079a29b in zif_mysqli_fetch_fields (ht=0, return_value=0xa4b8584, return_value_ptr=0x0, this_ptr=0xa5c9ca0, return_value_used=1) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1114 #3 0x083f3f03 in zend_do_fcall_common_helper_SPEC (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:316 #4 0x083f4b3f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:421 #5 0x083f32d2 in execute (op_array=0xa2743b4) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:107 #6 0x083c7718 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php-5.3.6/Zend/zend.c:1194 #7 0x0835bd0c in php_execute_script (primary_file=0xbf889e14) at /usr/src/web/php-5.3.6/main/main.c:2268 #8 0x0849121c in main (argc=2, argv=0xbf889f74) at /usr/src/web/php-5.3.6/sapi/cli/php_cli.c:1193 Missing separate debuginfos, use: debuginfo-install keyutils.i386 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=54646edit=1
Bug #53993 [Opn-Bgs]: Command out of sync after CALL
Edit report at http://bugs.php.net/bug.php?id=53993edit=1
ID: 53993
Updated by: u...@php.net
Reported by:doqnach at miraizou dot net
Summary:Command out of sync after CALL
-Status: Open
+Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: WinXP SP3 Win Server 2003 R2
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Sorry, but that's how it is. Check the docs and fetch all result sets
before running new statement.
Previous Comments:
[2011-05-09 15:05:53] u...@php.net
This is somewhat beyond the scope of the PHP drivers. The PHP drivers
follow MySQL Client Server protocol. Given you don't like the protocol
and its handling of certain queries - with the need to fetch result sets
in some cases - you should direct your request to the database vendor
but not to php.net and the PHP drivers. This is not a PHP driver
specific issue.
[2011-02-11 09:51:02] doqnach at miraizou dot net
Description:
I'm having problems doing a SELECT query after having done a CALL to a
stored procedure.
see bug #48065 and bug #35203
The statement by schwern at pobox dot com at bug #48065 clearly states
my view on this as well.
This 'issue' is not bogus and it's strange that you have to handle a
CALL completely different from a normal SELECT even though the rest of
the logic is exactly the same.
I have made a post at the mysql support forum when trying to figure out
what was going wrong which contains a working test script.
multi query should not have to be the only solution for this.
Test script:
---
http://forums.mysql.com/read.php?52,407069,407203#msg-407203
Expected result:
array(1) {
[0]=
array(1) {
[VERSION()]=
string(16) 5.1.51-community
}
}
array(1) {
[0]=
array(1) {
[VERSION()]=
string(16) 5.1.51-community
}
}
Actual result:
--
array(1) {
[0]=
array(1) {
[VERSION()]=
string(16) 5.1.51-community
}
}
object(mysqli)#1 (17) {
[affected_rows]=
int(1)
[client_info]=
string(48) mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $
[client_version]=
int(50007)
[connect_errno]=
int(0)
[connect_error]=
NULL
[errno]=
int(2014)
[error]=
string(52) Commands out of sync; you can't run this command now
[field_count]=
int(1)
[host_info]=
string(20) localhost via TCP/IP
[info]=
NULL
[insert_id]=
int(0)
[server_info]=
string(16) 5.1.51-community
[server_version]=
int(50151)
[sqlstate]=
string(5) HY000
[protocol_version]=
int(10)
[thread_id]=
int(12)
[warning_count]=
int(0)
}
Fatal error: Call to a member function fetch_assoc() on a non-object in
path\test_call.php on line 21
--
Edit this bug report at http://bugs.php.net/bug.php?id=53993edit=1
Bug #54642 [Asn-Fbk]: Compile w/ MySQLi on OSX fail
Edit report at http://bugs.php.net/bug.php?id=54642edit=1 ID: 54642 Updated by: johan...@php.net Reported by:grzegorz129 at gmail dot com Summary:Compile w/ MySQLi on OSX fail -Status: Assigned +Status: Feedback Type: Bug Package:Compile Failure Operating System: Mac OS X 10.6.8 PHP Version:Irrelevant Assigned To:mysql Block user comment: N Private report: N New Comment: Hi, can you add a line #undef ulong before /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c line 33? I can't reproduce it but from the error message it seems that there is a bad define somewhere. If this fixes this issue we'd have to find the source for this. Previous Comments: [2011-05-09 17:54:45] u...@php.net /usr/local/mysql/include/my_global.h:909: error: duplicate âunsignedâ This does not look like a PHP issue. I'm afraid /usr/local/mysql/include/my_global.h is beyond the scope of the php.net team. This file belongs to your MySQL distribution. You may want to consult Oracle/MySQL for help. [2011-05-01 00:31:39] grzegorz129 at gmail dot com browser autocompleted wrong title ... sry :) [2011-05-01 00:22:39] grzegorz129 at gmail dot com Description: PHP 5.3.3 wont compile due to mysqllib bug (newer PHP cant be builded due to LSAPI bug.. ehh). Test script: --- ./configure '--prefix=/usr/local/lsws/lsphp5' '--enable-cli' '--with-curl=/usr' '--with-gd' '--enable-exif' '--enable-gd-native-ttf' '--with-ttf' '--without-gettext' '--with-jpeg-dir=/opt/local' '--with-png-dir=/opt/local' '--with-freetype-dir=/opt/local' '--with-openssl=/usr' '--with-mcrypt=/opt/local' '--with-mhash' '--with-mysql-sock=/var/mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-mysql=/usr/local/mysql' '--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--with-pear' '--with-zlib-dir=/usr' '--enable-zip' '--with-iconv=/usr/local' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-sockets' '--enable-mbstring' '--enable-mbregex' '--with-litespeed' '--enable-shmop' '--enable-track-vars' '--enable-sysvsem' '--enable-sysvshm' '--enable-pcntl' '--enable-sigchild' '--with-libxml-dir=/usr' Actual result: -- /bin/sh /usr/local/lsws/phpbuild/php-5.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/mysqli/ -I/usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/ -DPHP_ATOM_INC -I/usr/local/lsws/phpbuild/php-5.3.3/include - I/usr/local/lsws/phpbuild/php-5.3.3/main -I/usr/local/lsws/phpbuild/php-5.3.3 - I/usr/local/lsws/phpbuild/php-5.3.3/ext/date/lib -I/usr/local/lsws/phpbuild/php- 5.3.3/ext/ereg/regex -I/usr/include/libxml2 -I/opt/local/include - I/opt/local/include/freetype2 -I/usr/local/include - I/usr/local/lsws/phpbuild/php-5.3.3/ext/mbstring/oniguruma - I/usr/local/lsws/phpbuild/php-5.3.3/ext/mbstring/libmbfl - I/usr/local/lsws/phpbuild/php-5.3.3/ext/mbstring/libmbfl/mbfl - I/usr/local/mysql/include -I/usr/local/lsws/phpbuild/php- 5.3.3/ext/sqlite3/libsqlite -I/usr/local/lsws/phpbuild/php-5.3.3/TSRM - I/usr/local/lsws/phpbuild/php-5.3.3/Zend -no-cpp-precomp -I/usr/local/include -g -O2 -fvisibility=hidden -c /usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/mysqli.c -o ext/mysqli/mysqli.lo In file included from /usr/local/mysql/include/my_global.h:76, from /usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/php_mysqli_structs.h:57, from /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c:33: /usr/local/mysql/include/my_config.h:326:1: warning: SIZEOF_SIZE_T redefined In file included from /usr/local/lsws/phpbuild/php-5.3.3/TSRM/tsrm_config.h:1, from /usr/local/lsws/phpbuild/php- 5.3.3/TSRM/tsrm_config_common.h:13, from /usr/local/lsws/phpbuild/php- 5.3.3/TSRM/tsrm_virtual_cwd.h:26, from /usr/local/lsws/phpbuild/php-5.3.3/main/php.h:410, from /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c:29: /usr/local/lsws/phpbuild/php-5.3.3/include/../main/php_config.h:151:1: warning: this is the location of the previous definition In file included from /usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/php_mysqli_structs.h:57, from /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c:33: /usr/local/mysql/include/my_global.h:909: error: duplicate âunsignedâ /usr/local/mysql/include/my_global.h:909: warning: useless type name in empty declaration make: *** [ext/mysqli/mysqli.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=54642edit=1
Bug #54642 [Fbk]: Compile w/ MySQLi on OSX fail
Edit report at http://bugs.php.net/bug.php?id=54642edit=1 ID: 54642 Updated by: johan...@php.net Reported by:grzegorz129 at gmail dot com Summary:Compile w/ MySQLi on OSX fail Status: Feedback Type: Bug Package:Compile Failure Operating System: Mac OS X 10.6.8 PHP Version:Irrelevant Assigned To:mysql Block user comment: N Private report: N New Comment: in fact this seems to be fixed as bug #52413 please test the patch from there. Previous Comments: [2011-05-10 17:18:23] johan...@php.net Hi, can you add a line #undef ulong before /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c line 33? I can't reproduce it but from the error message it seems that there is a bad define somewhere. If this fixes this issue we'd have to find the source for this. [2011-05-09 17:54:45] u...@php.net /usr/local/mysql/include/my_global.h:909: error: duplicate âunsignedâ This does not look like a PHP issue. I'm afraid /usr/local/mysql/include/my_global.h is beyond the scope of the php.net team. This file belongs to your MySQL distribution. You may want to consult Oracle/MySQL for help. [2011-05-01 00:31:39] grzegorz129 at gmail dot com browser autocompleted wrong title ... sry :) [2011-05-01 00:22:39] grzegorz129 at gmail dot com Description: PHP 5.3.3 wont compile due to mysqllib bug (newer PHP cant be builded due to LSAPI bug.. ehh). Test script: --- ./configure '--prefix=/usr/local/lsws/lsphp5' '--enable-cli' '--with-curl=/usr' '--with-gd' '--enable-exif' '--enable-gd-native-ttf' '--with-ttf' '--without-gettext' '--with-jpeg-dir=/opt/local' '--with-png-dir=/opt/local' '--with-freetype-dir=/opt/local' '--with-openssl=/usr' '--with-mcrypt=/opt/local' '--with-mhash' '--with-mysql-sock=/var/mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-mysql=/usr/local/mysql' '--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--with-pear' '--with-zlib-dir=/usr' '--enable-zip' '--with-iconv=/usr/local' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-sockets' '--enable-mbstring' '--enable-mbregex' '--with-litespeed' '--enable-shmop' '--enable-track-vars' '--enable-sysvsem' '--enable-sysvshm' '--enable-pcntl' '--enable-sigchild' '--with-libxml-dir=/usr' Actual result: -- /bin/sh /usr/local/lsws/phpbuild/php-5.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/mysqli/ -I/usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/ -DPHP_ATOM_INC -I/usr/local/lsws/phpbuild/php-5.3.3/include - I/usr/local/lsws/phpbuild/php-5.3.3/main -I/usr/local/lsws/phpbuild/php-5.3.3 - I/usr/local/lsws/phpbuild/php-5.3.3/ext/date/lib -I/usr/local/lsws/phpbuild/php- 5.3.3/ext/ereg/regex -I/usr/include/libxml2 -I/opt/local/include - I/opt/local/include/freetype2 -I/usr/local/include - I/usr/local/lsws/phpbuild/php-5.3.3/ext/mbstring/oniguruma - I/usr/local/lsws/phpbuild/php-5.3.3/ext/mbstring/libmbfl - I/usr/local/lsws/phpbuild/php-5.3.3/ext/mbstring/libmbfl/mbfl - I/usr/local/mysql/include -I/usr/local/lsws/phpbuild/php- 5.3.3/ext/sqlite3/libsqlite -I/usr/local/lsws/phpbuild/php-5.3.3/TSRM - I/usr/local/lsws/phpbuild/php-5.3.3/Zend -no-cpp-precomp -I/usr/local/include -g -O2 -fvisibility=hidden -c /usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/mysqli.c -o ext/mysqli/mysqli.lo In file included from /usr/local/mysql/include/my_global.h:76, from /usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/php_mysqli_structs.h:57, from /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c:33: /usr/local/mysql/include/my_config.h:326:1: warning: SIZEOF_SIZE_T redefined In file included from /usr/local/lsws/phpbuild/php-5.3.3/TSRM/tsrm_config.h:1, from /usr/local/lsws/phpbuild/php- 5.3.3/TSRM/tsrm_config_common.h:13, from /usr/local/lsws/phpbuild/php- 5.3.3/TSRM/tsrm_virtual_cwd.h:26, from /usr/local/lsws/phpbuild/php-5.3.3/main/php.h:410, from /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c:29: /usr/local/lsws/phpbuild/php-5.3.3/include/../main/php_config.h:151:1: warning: this is the location of the previous definition In file included from /usr/local/lsws/phpbuild/php- 5.3.3/ext/mysqli/php_mysqli_structs.h:57, from /usr/local/lsws/phpbuild/php-5.3.3/ext/mysqli/mysqli.c:33: /usr/local/mysql/include/my_global.h:909: error: duplicate âunsignedâ /usr/local/mysql/include/my_global.h:909: warning: useless type name in empty declaration make: *** [ext/mysqli/mysqli.lo] Error 1
Bug #54258 [Opn-Bgs]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
Edit report at http://bugs.php.net/bug.php?id=54258edit=1
ID: 54258
Updated by: u...@php.net
Reported by:an0nym at narod dot ru
Summary:MySQL: Silent ignorance of binds inside comments
causes other to be wrong bound
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thanks for explaining, but I still believe there is no error here.
You are running:
CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1))
UPDATE t SET /*field1 = : 1, */field2 = 2
SELECT * FROM t
You get:
1 row with field1 = 0, field2 = 2
That's pretty much what I expect.
You are setting:
PDO::ATTR_EMULATE_PREPARES = false));
But you are forcing parameter substitution on the client because you are
using :name instead of ? placeholder syntax. The MySQL server does
not support use of :name for placeholders in prepared statements.
Thus, PDO hooks in, does the string replacements and tells MySQL to
prepare:
UPDATE t SET /*f1 = ?, */f2 = ?
MySQL prepares it for you. Then, you bind parameters:
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
No error handling in your code. MySQL does what it is supposed to do
according to http://www.php.net/manual/en/pdostatement.bindparam.php. It
returns false for the second call to bindParam(), because there is only
one parameter to bind.
UPDATE t SET /*f1 = ?, */f2 = ?
^ comment
^ parameter to bind
MySQL sets f2 = 1. And, that's exactly what you get.
Please add proper error handling to your code.
Previous Comments:
[2011-05-10 12:56:43] an0nym at narod dot ru
As you can see f2 is silently updated to 1 instead of exception (at
least) or right value 2.
[2011-05-10 12:55:23] an0nym at narod dot ru
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:53:51 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:53:56 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:54:02 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false));
$DB-exec(CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1)) SELECT
0 f1, 0 f2);
$stmt = $DB-prepare(UPDATE t SET /*f1 = :field1, */f2 = :field2);
$field1 = 1;
$field2 = 2;
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
$stmt-execute();
foreach ($DB-query(SELECT * FROM t) as $row)
var_dump($row);
06:54:07 ~
root@test # php test.php
bool(false)
array(4) {
[f1]=
string(1) 0
[0]=
string(1) 0
[f2]=
string(1) 1
[1]=
string(1) 1
}
06:54:11 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:54:47 ~
root@test #
[2011-05-10 09:56:54] u...@php.net
Can't reproduce. Please, provide full example including connect, create
table, error handling and so forth.
[2011-03-15 16:30:52] an0nym at narod dot ru
Description:
See test script.
Test script:
---
$statement = $DB-prepare(UPDATE t SET /*field1 = :field1, */field2 =
:field2);
$field1 = 1;
$field2 = 2;
$statement-bindParam(:field1, $field1, PDO::PARAM_INT);
$statement-bindParam(:field2, $field2, PDO::PARAM_INT);
$statement-execute();
Expected result:
Query UPDATE t SET /*field1 = 1, */field2 = 2 or error message like
wrong param count.
Actual result:
--
Silently running query UPDATE t SET /*field1 = ?, */field2 = 1.
--
Edit this bug report
Bug #54258 [Bgs]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
Edit report at http://bugs.php.net/bug.php?id=54258edit=1
ID: 54258
Updated by: u...@php.net
Reported by:an0nym at narod dot ru
Summary:MySQL: Silent ignorance of binds inside comments
causes other to be wrong bound
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
... uups mixed up 1 and 2 at the beginning. But still: bogus.
Previous Comments:
[2011-05-10 17:43:54] u...@php.net
Thanks for explaining, but I still believe there is no error here.
You are running:
CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1))
UPDATE t SET /*field1 = : 1, */field2 = 2
SELECT * FROM t
You get:
1 row with field1 = 0, field2 = 2
That's pretty much what I expect.
You are setting:
PDO::ATTR_EMULATE_PREPARES = false));
But you are forcing parameter substitution on the client because you are
using :name instead of ? placeholder syntax. The MySQL server does
not support use of :name for placeholders in prepared statements.
Thus, PDO hooks in, does the string replacements and tells MySQL to
prepare:
UPDATE t SET /*f1 = ?, */f2 = ?
MySQL prepares it for you. Then, you bind parameters:
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
No error handling in your code. MySQL does what it is supposed to do
according to http://www.php.net/manual/en/pdostatement.bindparam.php. It
returns false for the second call to bindParam(), because there is only
one parameter to bind.
UPDATE t SET /*f1 = ?, */f2 = ?
^ comment
^ parameter to bind
MySQL sets f2 = 1. And, that's exactly what you get.
Please add proper error handling to your code.
[2011-05-10 12:56:43] an0nym at narod dot ru
As you can see f2 is silently updated to 1 instead of exception (at
least) or right value 2.
[2011-05-10 12:55:23] an0nym at narod dot ru
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:53:51 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:53:56 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:54:02 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false));
$DB-exec(CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1)) SELECT
0 f1, 0 f2);
$stmt = $DB-prepare(UPDATE t SET /*f1 = :field1, */f2 = :field2);
$field1 = 1;
$field2 = 2;
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
$stmt-execute();
foreach ($DB-query(SELECT * FROM t) as $row)
var_dump($row);
06:54:07 ~
root@test # php test.php
bool(false)
array(4) {
[f1]=
string(1) 0
[0]=
string(1) 0
[f2]=
string(1) 1
[1]=
string(1) 1
}
06:54:11 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:54:47 ~
root@test #
[2011-05-10 09:56:54] u...@php.net
Can't reproduce. Please, provide full example including connect, create
table, error handling and so forth.
[2011-03-15 16:30:52] an0nym at narod dot ru
Description:
See test script.
Test script:
---
$statement = $DB-prepare(UPDATE t SET /*field1 = :field1, */field2 =
:field2);
$field1 = 1;
$field2 = 2;
$statement-bindParam(:field1, $field1, PDO::PARAM_INT);
$statement-bindParam(:field2, $field2, PDO::PARAM_INT);
$statement-execute();
Expected result:
Query UPDATE t SET /*field1 = 1, */field2 = 2 or error message like
wrong param count.
Actual result:
--
Silently running
Bug #54583 [Asn]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583edit=1
ID: 54583
Updated by: u...@php.net
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
Status: Assigned
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
There are more pointers in MYSQL_BIND. I might have missed some in the
patch.
Previous Comments:
[2011-05-10 13:47:14] u...@php.net
Affects libmysql only. No issue when using mysqlnd.
Johannes, please review and apply patch:
nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_3 svn diff
ext/pdo_mysql/
Index: ext/pdo_mysql/mysql_statement.c
===
--- ext/pdo_mysql/mysql_statement.c (Revision 310880)
+++ ext/pdo_mysql/mysql_statement.c (Arbeitskopie)
@@ -136,6 +136,7 @@
{
pdo_mysql_stmt *S = stmt-driver_data;
pdo_mysql_db_handle *H = S-H;
+ int paramno;
PDO_DBG_ENTER(pdo_mysql_stmt_execute_prepared_libmysql);
@@ -143,6 +144,10 @@
if (mysql_stmt_bind_param(S-stmt, S-params) ||
mysql_stmt_execute(S-stmt)) {
if (S-params) {
memset(S-params, 0, S-num_params *
sizeof(MYSQL_BIND));
+ for (paramno = 0; paramno S-num_params;
paramno++) {
+ S-params[paramno].is_null =
S-in_null[paramno];
+ S-params[paramno].length =
S-in_length[paramno];
+ }
}
pdo_mysql_error_stmt(stmt);
if (mysql_stmt_errno(S-stmt) == 2057) {
[2011-05-10 12:36:54] an0nym at narod dot ru
Sorry, CentOS is with mysqlnd now. Testing on Fedora:
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:32:59 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:33:02 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:33:06 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
PDO::MYSQL_ATTR_INIT_COMMAND = SET SQL_MODE =
'STRICT_ALL_TABLES'));
$DB-exec(CREATE TEMPORARY TABLE t(f VARCHAR(1)));
$stmt = $DB-prepare(INSERT INTO t VALUES(:value));
$value = aa;
$stmt-bindParam(:value, $value);
try {
$stmt-execute();
} catch (PDOException $e) {}
$stmt-execute();
06:33:17 ~
root@test # php test.php
bool(false)
Segmentation fault
06:33:24 ~
root@test # mysql -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.1.56 Source distribution
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights
reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2
license
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql exit
Bye
06:34:43 ~
root@test #
[2011-05-10 10:15:36] u...@php.net
Which version of libmysql is used, what's the server version?
[2011-04-22 17:23:13] an0nym at narod dot ru
Everything works fine with php5.3.5 + mysqlnd @ winsrv2008r2x64. So it
seems that
the error is with libmysql only.
[2011-04-21 11:56:55] an0nym at narod dot ru
Try new test code, please. I will submit backtrace when I manage to
generate it.
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=54583
--
Edit this bug report at http://bugs.php.net/bug.php?id=54583edit=1
Bug #53960 [Bgs]: Invalid parameter number for multiple params equals in query
Edit report at http://bugs.php.net/bug.php?id=53960edit=1
ID: 53960
User updated by:contato at andersonfraga dot net
Reported by:contato at andersonfraga dot net
Summary:Invalid parameter number for multiple params
equals in query
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Windows
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Anyway...
I think it should work, right?
'Even more because' it works in 5.2.14..
Previous Comments:
[2011-05-10 10:03:11] u...@php.net
SQL - 2x hash_1:
AND (NOME_CLIENTE LIKE :hash_1
OR ENDERECO_CLIENTE LIKE :hash_1)
PHP bind - 1x hash_1, 1x hash_2:
$statement-execute(Array(
':hash_1' = '%Anderson%',
':hash_2' = 0,
[2011-02-08 17:27:49] contato at andersonfraga dot net
Description:
This error is occurring when I use the same parameter several times in
the query.
In PHP 5.2.14, using Gentoo, it works perfectly. Already in versions
5.3.0 and 5.3.3 (using Windows on both), returns an exception.
Bug or 'feature'?
Test script:
---
?php
try {
$dbh = new PDO('mysql:/*irrelevant*/', Array(
PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false,
));
$select = SELECT * FROM PR_CLIENTE
WHERE DELETADO = 'N'
AND (NOME_CLIENTE LIKE :hash_1
OR ENDERECO_CLIENTE LIKE :hash_1)
ORDER BY ID_CLIENTE DESC
LIMIT :hash_2;;
$statement = $dbh-prepare($select);
$statement-execute(Array(
':hash_1' = '%Anderson%',
':hash_2' = 0,
));
$fetch = $statement-fetchAll(PDO::FETCH_ASSOC);
print_r($fetch);
}
catch(PDOException $e) {
print_r($e-getMessage());
}
?
Expected result:
Array
(
[0] = Array
(
[ID_CLIENTE] = 29
(...)
)
)
Actual result:
--
SQLSTATE[HY093]: Invalid parameter number
--
Edit this bug report at http://bugs.php.net/bug.php?id=53960edit=1
Bug #54646 [Fbk-Opn]: segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54646edit=1 ID: 54646 User updated by:public at grik dot net Reported by:public at grik dot net Summary:segmentation fault -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I'll try with the last MySQL 5.5.11 Previous Comments: [2011-05-10 16:58:16] u...@php.net Glad to hear mysqlnd works fine. Its impossible to tell what could be going on with libmysql by just checking the backtrace. You seem to be using an older version of MySQL/libmysql. Could you try a recent version of libmysql? Also, as hard as it is, it would be most helpful to get a reproducible test script. [2011-05-01 21:14:07] public at grik dot net Sorry, I meant backtrace. Or you need some other one? [2011-05-01 21:06:41] public at grik dot net I am sorry, but the bugtrace is already posted in the report. [2011-05-01 14:27:55] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2011-05-01 14:26:47] public at grik dot net Description: I observe a segfault when running a xenforo package in debug mode. The configuration of the server is Fedora Core 8, MySQL 5.0.45 I recompiled PHP with debug mode and turned off all extensions not from the standard archive. I found a way to avoid it by recompiling the mysqli extension with mysqlnd driver. I am not really sure if it was worth to open this report as I don't know how you can reproduce it, but at least you'll hear about the issue. Test script: --- I am not sure I can make a minimal reproducable case. Xenforo is a large package based on Zend Framework. any call to the xenforo scripts in debug mode crashes php, both fcgi and cli Actual result: -- backtrace: Core was generated by `php index.php'. Program terminated with signal 11, Segmentation fault. #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 catalog, key_len=8, str=0x665f696b Address 0x665f696b out of bounds, duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 1524 ZVAL_STRING(tmp, str, duplicate); (gdb) bt #0 0x083ccebc in add_property_string_ex (arg=0xa62c714, key=0x7a6fb4 catalog, key_len=8, str=0x665f696b Address 0x665f696b out of bounds, duplicate=1) at /usr/src/web/php-5.3.6/Zend/zend_API.c:1524 #1 0x00799f0c in php_add_field_properties (value=0xa62c714, field=0xa2aea28) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1056 #2 0x0079a29b in zif_mysqli_fetch_fields (ht=0, return_value=0xa4b8584, return_value_ptr=0x0, this_ptr=0xa5c9ca0, return_value_used=1) at /usr/src/web/php-5.3.6/ext/mysqli/mysqli_api.c:1114 #3 0x083f3f03 in zend_do_fcall_common_helper_SPEC (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:316 #4 0x083f4b3f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xa055c50) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:421 #5 0x083f32d2 in execute (op_array=0xa2743b4) at /usr/src/web/php-5.3.6/Zend/zend_vm_execute.h:107 #6 0x083c7718 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php-5.3.6/Zend/zend.c:1194 #7 0x0835bd0c in php_execute_script (primary_file=0xbf889e14) at /usr/src/web/php-5.3.6/main/main.c:2268 #8 0x0849121c in main (argc=2, argv=0xbf889f74) at /usr/src/web/php-5.3.6/sapi/cli/php_cli.c:1193 Missing separate debuginfos, use: debuginfo-install keyutils.i386 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=54646edit=1
Bug #54367 [Csd-ReO]: Use of closure causes problem in ArrayAccess
Edit report at http://bugs.php.net/bug.php?id=54367edit=1
ID: 54367
Updated by: tony2...@php.net
Reported by:jpa...@php.net
Summary:Use of closure causes problem in ArrayAccess
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The test for this bug causes invalid read and subsequent segfault in 5_3
(but works fine in trunk):
==17645== Invalid read of size 8
==17645==at 0x93625F: _zval_ptr_dtor (zend_execute_API.c:446)
==17645==by 0x97BAD6: zend_leave_helper_SPEC
(zend_vm_execute.h:167)
==17645==by 0x980ACE: ZEND_RETURN_SPEC_CONST_HANDLER
(zend_vm_execute.h:1714)
==17645==by 0x97B8E6: execute (zend_vm_execute.h:107)
==17645==by 0x947FBE: zend_execute_scripts (zend.c:1194)
==17645==by 0x8D2E56: php_execute_script (main.c:2275)
==17645==by 0xA2C0A5: main (php_cli.c:1193)
==17645== Address 0xa74fb98 is 56 bytes inside a block of size 264
free'd
==17645==at 0x4C2599C: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17645==by 0x922C77: _efree (zend_alloc.c:2358)
==17645==by 0x96F0A9: zend_closure_free_storage
(zend_closures.c:190)
==17645==by 0x975C47: zend_objects_store_del_ref_by_handle_ex
(zend_objects_API.c:220)
==17645==by 0x9759AE: zend_objects_store_del_ref
(zend_objects_API.c:172)
==17645==by 0x945591: _zval_dtor_func (zend_variables.c:52)
==17645==by 0x93528B: _zval_dtor (zend_variables.h:35)
==17645==by 0x93625A: _zval_ptr_dtor (zend_execute_API.c:445)
==17645==by 0x97BAD6: zend_leave_helper_SPEC
(zend_vm_execute.h:167)
==17645==by 0x980ACE: ZEND_RETURN_SPEC_CONST_HANDLER
(zend_vm_execute.h:1714)
==17645==by 0x97B8E6: execute (zend_vm_execute.h:107)
==17645==by 0x947FBE: zend_execute_scripts (zend.c:1194)
Previous Comments:
[2011-04-20 15:00:11] dmi...@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.
[2011-04-20 14:59:21] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=310389
Log: Fixed bug #54367 (Use of closure causes problem in ArrayAccess).
[2011-03-25 09:55:25] jpa...@php.net
Felipe: strange, I got no crash with your code (5.3.6,Linux,
self-compiled)
[2011-03-24 22:49:49] fel...@php.net
I can reproduce a crash with:
?php
class MyObjet implements ArrayAccess
{
public function __construct() { }
public function offsetSet($offset, $value) { }
public function offsetExists($offset) { }
public function offsetUnset($offset) { }
public function offsetGet ($offset) {
return function () { };
}
}
$a = new MyObjet();
echo $a['p']('foo');
?
Breakpoint 1, 0x085368b3 in ZEND_SEND_VAL_SPEC_CONST_HANDLER
(execute_data=0x8ade614, tsrm_ls=0x89022a0)
at /home/felipe/dev/php5/Zend/zend_vm_execute.h:1719
1719 ARG_MUST_BE_SENT_BY_REF(EX(fbc),
opline-op2.u.opline_num)) {
(gdb) p execute_data-fbc-common
$7 = {type = 90 'Z', function_name = 0x5a5a5a5a Address 0x5a5a5a5a out
of bounds, scope = 0x5a5a5a5a, fn_flags = 1515870810,
prototype = 0x5a5a5a5a, num_args = 1515870810, required_num_args =
1515870810, arg_info = 0x5a5a5a5a, pass_rest_by_reference = 90 'Z',
return_reference = 90 'Z'}
[2011-03-24 13:52:23] jpa...@php.net
Description:
Closures cant use variables from external context when the context is in
ArrayAccess method
Test script:
---
?php
class MyObjet implements ArrayAccess
{
// All the stuff for ArrayAccess
public function offsetGet ($offset)
{
return function ($var) use ($offset) { // here is the problem
return sprintf('%s%s/%$1s', $offset, $var);
};
}
}
$a = new MyObjet();
echo $a['p']('foo');
Expected result:
pfoo/p
Actual result:
--
PHP Notice: Undefined variable: offset in {file.php} on line 11
--
Edit this bug report at http://bugs.php.net/bug.php?id=54367edit=1
[PHP-BUG] Bug #54702 [NEW]: character @ not handled properly with \b
From:
Operating system: Linux
PHP version: Irrelevant
Package: PCRE related
Bug Type: Bug
Bug description:character @ not handled properly with \b
Description:
Hi,
I have a problem with the @ character at the end of a word, with the word
delimiter \b:
input: i wrote this exampl@ for you
preg_match('/\bexampl@/','i wrote this exampl@ for you') = 1
preg_match('/\bexampl@\b/','i wrote this exampl@ for you') = 0
the second preg_match should also return 1 !!
Test script:
---
?php
$input='i wrote this exampl@ for you';
echo input: .$input.\n;
$patt='/\bexampl@/';
echo preg_match('.$patt.','.$input.') = .preg_match($patt,
$input).\n;
$patt='/\bexampl@\b/';
echo preg_match('.$patt.','.$input.') = .preg_match($patt,
$input).\n;
?
Expected result:
for both preg_match, output should be 1, that is, the pattern should be
found in the input string
preg_match('/\bexampl@/','i wrote this exampl@ for you') = 1
preg_match('/\bexampl@\b/','i wrote this exampl@ for you') = 1
Actual result:
--
preg_match('/\bexampl@/','i wrote this exampl@ for you') = 1
preg_match('/\bexampl@\b/','i wrote this exampl@ for you') = 0
--
Edit bug report at http://bugs.php.net/bug.php?id=54702edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54702r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54702r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54702r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54702r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54702r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54702r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54702r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54702r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54702r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54702r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54702r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54702r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54702r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54702r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54702r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54702r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54702r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54702r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54702r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54702r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54702r=mysqlcfg
[PHP-BUG] Bug #54703 [NEW]: When containing a null character, $_GET variable not set (properly)
From:
Operating system:
PHP version: 5.2.17
Package: *General Issues
Bug Type: Bug
Bug description:When containing a null character, $_GET variable not set
(properly)
Description:
When a null character is present in the value of a variable in the request
string (encoded as %00), said variable will either not be set in $_GET at
all (linux) or be set improperly (null character is escaped; win32)
Test script:
---
?php
print_r($_GET);
if (isset($_GET['fb']))
{
echo strlen($_GET['fb']);
}
else
{
echo 'a href=?fb=foo%00barclick me/a';
}
Expected result:
After clicking the link:
Array
(
[fb] = foo�bar
)
7
Actual result:
--
After clicking the link:
- On a linux setup:
Array
(
)
a href=?fb=foo%00barclick me/a
- On a win32 setup:
Array
(
[fb] = foo\0bar
)
8
--
Edit bug report at http://bugs.php.net/bug.php?id=54703edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54703r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54703r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54703r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54703r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54703r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54703r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54703r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54703r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54703r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54703r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54703r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54703r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54703r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54703r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54703r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54703r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54703r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54703r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54703r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54703r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54703r=mysqlcfg
Req #32734 [Com]: Support for #line pragma, as in C and Perl
Edit report at http://bugs.php.net/bug.php?id=32734edit=1
ID: 32734
Comment by: rasmus at mindplay dot dk
Reported by:php at koterov dot ru
Summary:Support for #line pragma, as in C and Perl
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: all
PHP Version:5.0.4
Block user comment: N
Private report: N
New Comment:
This feature is badly lacking to support many good, modern patterns,
which could broaden the scope and use of PHP in general. View-engines as
mentioned, but not least aspect-oriented programming, code generation
and meta-programming in general, and cross-language-compilation from
other languages.
Microsoft's C# compiler has an implementation of this feature that could
be referenced:
http://msdn.microsoft.com/en-us/library/aa691102%28v=VS.71%29.aspx
I would propose extending the existing syntax for execution directives,
as implemented by the declare keyword:
http://www.php.net/manual/en/control-structures.declare.php
It might looks like this:
// start of file
declare(source='test.c#20');
something();
declare(source='test.c#30') {
other();
more();
}
// end of file
Consistent with the way declare otherwise works - the first
declare-statement in this example changes the error-reporting for all of
the following statements in that file, while the second
declare-statement changes the error reporting within the brackets.
I think this idea should be taken into serious consideration, as it has
the potential to open up the world of PHP to entirely new forms of
development.
Previous Comments:
[2005-04-17 08:47:01] php at koterov dot ru
Description:
C, C++ and Perl support the folowing feature:
// start of file
#line 20 test.c
something
#line 30 test.c
other
// end of file
If error is generated into code something, it is reported as error in
test.c on line 20 - NOT on line 3! For code other - in test.c on
line 30. The same Perl code example:
### start of file
#line 20 test.c
warn something;
#line 30 test.c
warn other;
### end of file
Result is:
something at test.c line 20.
other at test.c line 30.
Unfortunately PHP does not support this useful feature, and because of
that any template engines with pre-compilation (e.g. Smarty) make the
life not so pleasant as it could be.
Do you plan to add #line feature in future versions of PHP? Programmers
need it very much!
--
Edit this bug report at http://bugs.php.net/bug.php?id=32734edit=1
Bug #54703 [Opn-Fbk]: When containing a null character, $_GET variable not set (properly)
Edit report at http://bugs.php.net/bug.php?id=54703edit=1
ID: 54703
Updated by: ras...@php.net
Reported by:php at tracking-celebs dot info
Summary:When containing a null character, $_GET variable not
set (properly)
-Status: Open
+Status: Feedback
Type: Bug
Package:*General Issues
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
On Linux this is not true unless you have something specifically
filtering these
on you. Without ext/filter, suhosin or your own filter code, nulls go
through
fine. See: http://progphp.com/null.php?fb=foo%00bar
And the source for the script: http://progphp.com/null.phps
And it shouldn't be any different on Windows.
Previous Comments:
[2011-05-10 19:21:28] php at tracking-celebs dot info
Description:
When a null character is present in the value of a variable in the
request string (encoded as %00), said variable will either not be set in
$_GET at all (linux) or be set improperly (null character is escaped;
win32)
Test script:
---
?php
print_r($_GET);
if (isset($_GET['fb']))
{
echo strlen($_GET['fb']);
}
else
{
echo 'a href=?fb=foo%00barclick me/a';
}
Expected result:
After clicking the link:
Array
(
[fb] = foo�bar
)
7
Actual result:
--
After clicking the link:
- On a linux setup:
Array
(
)
a href=?fb=foo%00barclick me/a
- On a win32 setup:
Array
(
[fb] = foo\0bar
)
8
--
Edit this bug report at http://bugs.php.net/bug.php?id=54703edit=1
Bug #54258 [Bgs]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
Edit report at http://bugs.php.net/bug.php?id=54258edit=1
ID: 54258
User updated by:an0nym at narod dot ru
Reported by:an0nym at narod dot ru
Summary:MySQL: Silent ignorance of binds inside comments
causes other to be wrong bound
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
No error handling in your code. MySQL does what it is supposed to do
according
to http://www.php.net/manual/en/pdostatement.bindparam.php. It returns
false for
the second call to bindParam(), because there is only one parameter to
bind.
UPDATE t SET /*f1 = ?, */f2 = ?
^ comment
^ parameter to bind
MySQL sets f2 = 1. And, that's exactly what you get.
Yeap, MySQL does. Nope, PDO doesn't.
cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false));
$DB-exec(CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1)) SELECT
0 f1, 0
f2);
$stmt = $DB-prepare(UPDATE t SET /*f1 = :field1, */f2 = :field2);
$field1 = 1;
$field2 = 2;
var_dump($stmt-bindParam(:field1, $field1),
$stmt-bindParam(:field2, $field2));
$stmt-execute();
foreach ($DB-query(SELECT * FROM t) as $row)
var_dump($row);
php test.php
bool(true)
bool(true)
bool(false)
array(4) {
[f1]=
string(1) 0
[0]=
string(1) 0
[f2]=
string(1) 1
[1]=
string(1) 1
}
As you can see, PDO returned TRUE binding :field1 = $field1 and FALSE
binding
:field2 = $field2. However, actually it silently bound :field2 =
$field1. I
understand why - MySQL doesn't have named placeholders and doesn't tell
us about
placeholder inside comment it skipped. Nevertheless, PDO did the
opposite to
what it reported about.
Obviously, it is a bug, maybe the one that won't be fixed based on
objective
reasons.
Previous Comments:
[2011-05-10 17:44:40] u...@php.net
... uups mixed up 1 and 2 at the beginning. But still: bogus.
[2011-05-10 17:43:54] u...@php.net
Thanks for explaining, but I still believe there is no error here.
You are running:
CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1))
UPDATE t SET /*field1 = : 1, */field2 = 2
SELECT * FROM t
You get:
1 row with field1 = 0, field2 = 2
That's pretty much what I expect.
You are setting:
PDO::ATTR_EMULATE_PREPARES = false));
But you are forcing parameter substitution on the client because you are
using :name instead of ? placeholder syntax. The MySQL server does
not support use of :name for placeholders in prepared statements.
Thus, PDO hooks in, does the string replacements and tells MySQL to
prepare:
UPDATE t SET /*f1 = ?, */f2 = ?
MySQL prepares it for you. Then, you bind parameters:
$stmt-bindParam(:field1, $field1, PDO::PARAM_INT);
$stmt-bindParam(:field2, $field2, PDO::PARAM_INT);
No error handling in your code. MySQL does what it is supposed to do
according to http://www.php.net/manual/en/pdostatement.bindparam.php. It
returns false for the second call to bindParam(), because there is only
one parameter to bind.
UPDATE t SET /*f1 = ?, */f2 = ?
^ comment
^ parameter to bind
MySQL sets f2 = 1. And, that's exactly what you get.
Please add proper error handling to your code.
[2011-05-10 12:56:43] an0nym at narod dot ru
As you can see f2 is silently updated to 1 instead of exception (at
least) or right value 2.
[2011-05-10 12:55:23] an0nym at narod dot ru
root@test # uname -a
Linux test 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
06:53:51 ~
root@test # php -v
PHP 5.3.6 (cli) (built: Mar 17 2011 20:56:13)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
06:53:56 ~
root@test # find / | grep libmysql
/usr/lib64/mysql/libmysqlclient.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0
/usr/lib64/mysql/libmysqlclient_r.so.16
/usr/lib64/mysql/libmysqlclient.so.16
06:54:02 ~
root@test # cat test.php
?php
var_dump(function_exists(mysqli_fetch_all));
$DB = new PDO(mysql:dbname=test;host=localhost, root, ,
array(PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES = false));
$DB-exec(CREATE TEMPORARY TABLE t(f1 VARCHAR(1), f2 VARCHAR(1)) SELECT
0 f1, 0 f2);
$stmt =
Bug #54703 [Fbk-Opn]: When containing a null character, $_GET variable not set (properly)
Edit report at http://bugs.php.net/bug.php?id=54703edit=1
ID: 54703
User updated by:php at tracking-celebs dot info
Reported by:php at tracking-celebs dot info
Summary:When containing a null character, $_GET variable not
set (properly)
-Status: Feedback
+Status: Open
Type: Bug
Package:*General Issues
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
On that linux machine there is suhosin indeed, so it could be causing
the problem. I just tried on another computer with a new vanilla
php-5.2.17 and then got the same results as did on windows.
Would seem indeed to be caused by suhosin; however i just added suhosin
on there and it still worked then as before, so there must be something
else on that other computer...
Anyways, can't reproduce it with a vanilla php, so that's that. I got
things mixed up, seems there's no bug here after all; Apologies.
Previous Comments:
[2011-05-10 19:39:23] ras...@php.net
On Linux this is not true unless you have something specifically
filtering these
on you. Without ext/filter, suhosin or your own filter code, nulls go
through
fine. See: http://progphp.com/null.php?fb=foo%00bar
And the source for the script: http://progphp.com/null.phps
And it shouldn't be any different on Windows.
[2011-05-10 19:21:28] php at tracking-celebs dot info
Description:
When a null character is present in the value of a variable in the
request string (encoded as %00), said variable will either not be set in
$_GET at all (linux) or be set improperly (null character is escaped;
win32)
Test script:
---
?php
print_r($_GET);
if (isset($_GET['fb']))
{
echo strlen($_GET['fb']);
}
else
{
echo 'a href=?fb=foo%00barclick me/a';
}
Expected result:
After clicking the link:
Array
(
[fb] = foo�bar
)
7
Actual result:
--
After clicking the link:
- On a linux setup:
Array
(
)
a href=?fb=foo%00barclick me/a
- On a win32 setup:
Array
(
[fb] = foo\0bar
)
8
--
Edit this bug report at http://bugs.php.net/bug.php?id=54703edit=1
Bug #54702 [Opn-Bgs]: character @ not handled properly with \b
Edit report at http://bugs.php.net/bug.php?id=54702edit=1
ID: 54702
Updated by: fel...@php.net
Reported by:gwbv at yahoo dot com
Summary:character @ not handled properly with \b
-Status: Open
+Status: Bogus
Type: Bug
Package:PCRE related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This is not a bug.
From PCRE library documentation:
\Biss\B
which finds occurrences of iss in the middle of words. (\B
matches
only if the current position in the subject is not a word
boundary.)
I.e. \b just makes sense surrounding another word.
re /!\b/
data !
No match
data
re /a\b/
data abc a
0: a
Previous Comments:
[2011-05-10 19:02:35] gwbv at yahoo dot com
Description:
Hi,
I have a problem with the @ character at the end of a word, with the
word delimiter \b:
input: i wrote this exampl@ for you
preg_match('/\bexampl@/','i wrote this exampl@ for you') = 1
preg_match('/\bexampl@\b/','i wrote this exampl@ for you') = 0
the second preg_match should also return 1 !!
Test script:
---
?php
$input='i wrote this exampl@ for you';
echo input: .$input.\n;
$patt='/\bexampl@/';
echo preg_match('.$patt.','.$input.') = .preg_match($patt,
$input).\n;
$patt='/\bexampl@\b/';
echo preg_match('.$patt.','.$input.') = .preg_match($patt,
$input).\n;
?
Expected result:
for both preg_match, output should be 1, that is, the pattern should be
found in the input string
preg_match('/\bexampl@/','i wrote this exampl@ for you') = 1
preg_match('/\bexampl@\b/','i wrote this exampl@ for you') = 1
Actual result:
--
preg_match('/\bexampl@/','i wrote this exampl@ for you') = 1
preg_match('/\bexampl@\b/','i wrote this exampl@ for you') = 0
--
Edit this bug report at http://bugs.php.net/bug.php?id=54702edit=1
