Bug #64870 [Opn-Fbk]: mysqlnd: can't connect to updated MySQL server with old_password Off
Edit report at https://bugs.php.net/bug.php?id=64870edit=1
ID: 64870
Updated by: u...@php.net
Reported by:marceloinxs at gmail dot com
Summary:mysqlnd: can't connect to updated MySQL server with
old_password Off
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: Windows 7 64bit
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
Please, provide a Whireshark recording of the failed connection attempt. Thanks.
Previous Comments:
[2013-05-27 17:20:26] marceloinxs at gmail dot com
old_passwords is a configuration variable/flag in the MySQL configuration file.
It is set Off (as SHOW GLOBAL VARIABLES statement shows). I don't have admin
privileges for the database and no possibility to change config values. But I
can connect using a Linux server, so the problem seems to be enterily related
with mysqlnd Windows driver.
[2013-05-26 17:29:02] hanskrentel at yahoo dot de
The weird thing is that the database is actually MySQL 5.5.24, old_password
variable is Off and passwords are actually 41 byte encoded.
You write variable here. The error message clearly directs you to the
configuration file (which is *not* a variable).
Please check your configuration file and report back which related settings
you've
got in there.
[2013-05-17 16:44:57] marceloinxs at gmail dot com
Description:
Windows 7 build 7601, Apache 2.2.24 (Win32). Upgraded PHP from 5.2.* to 5.4.15,
mysql_* and mysqli_* can't connect to any databases. Then downgraded to 5.3.25,
same result.
The error is always the same:
PHP Warning: mysqli::mysqli() [a href='mysqli.mysqli'mysqli.mysqli/a]:
Premature end of data (mysqlnd_wireprotocol.c:553)
PHP Warning: mysqli::mysqli() [a href='mysqli.mysqli'mysqli.mysqli/a]: OK
packet 1 bytes shorter than expected
PHP Warning: mysqli::mysqli() [a href='mysqli.mysqli'mysqli.mysqli/a]:
(HY000/2000): mysqlnd cannot connect to MySQL 4.1+ using the old insecure
authentication. Please use an administration tool to reset your password with
the command SET PASSWORD = PASSWORD('your_existing_password'). This will store
a new, and more secure, hash value in mysql.user. If this user is used in other
scripts executed by PHP 5.2 or earlier you might need to remove the
old-passwords flag from your my.cnf file
The weird thing is that the database is actually MySQL 5.5.24, old_password
variable is Off and passwords are actually 41 byte encoded.
The database is remote, but remote connections are allowed. I even tried the
same script in Linux based server (PHP 5.4.10) and it worked.
Both mysql and mysqli extensions are correctly loaded in php.ini.
The main difference between PHP 5.2 and newer versions is that they now use
mysqlnd as driver. Maybe it is buggy in Windows?
You can have an extended look of this here:
http://stackoverflow.com/questions/16598572/mysqlnd-cannot-connect-to-mysql-5-5-24-old-password-is-off
Test script:
---
?php
$mysqli = new mysqli('aaa', 'bbb', 'ccc', 'ddd');
if($mysqli-connect_error) {
die( $mysqli-connect_error );
}
echo 'connected';
?
Expected result:
'connected'
Actual result:
--
Warning: mysqli::mysqli() [mysqli.mysqli]: Premature end of data
(mysqlnd_wireprotocol.c:553) in ... on line 3
Warning: mysqli::mysqli() [mysqli.mysqli]: OK packet 9 bytes shorter than
expected in ... on line 3
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2000): mysqlnd cannot connect
to MySQL 4.1+ using the old insecure authentication. Please use an
administration tool to reset your password with the command SET PASSWORD =
PASSWORD('your_existing_password'). This will store a new, and more secure,
hash value in mysql.user. If this user is used in other scripts executed by PHP
5.2 or earlier you might need to remove the old-passwords flag from your my.cnf
file in ... on line 3
mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication.
Please use an administration tool to reset your password with the command SET
PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more
secure, hash value in mysql.user. If this user is used in other scripts
executed by PHP 5.2 or earlier you might need to remove the old-passwords flag
from your my.cnf file
--
Edit this bug report at https://bugs.php.net/bug.php?id=64870edit=1
Req #64844 [Opn-Nab]: PDO::quote() for mysql driver (wrong apostrophe replacing)
Edit report at https://bugs.php.net/bug.php?id=64844edit=1 ID: 64844 Updated by: u...@php.net Reported by:mariusz dot gomse at baobaz dot com Summary:PDO::quote() for mysql driver (wrong apostrophe replacing) -Status: Open +Status: Not a bug Type: Feature/Change Request Package:PDO related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The cited bug is an InnoDB server bug. Unrelated to driver. Previous Comments: [2013-05-15 15:57:57] mariusz dot gomse at baobaz dot com Description: According to http://bugs.mysql.com/bug.php?id=61656 mysql bug PDO::quote() method shouldn't change ' to \' for mysql driver. Should change for ''. Test script: --- ?php $tmp = Let's go!; $pdo = new PDO(mysql:host=localhost;initStatements=SET NAMES utf8;model=mysql4;type=pdo_mysql;pdoType=;active=1, 'root', '', array()); echo $pdo-quote($tmp); ? Expected result: 'Let''s go!' Actual result: -- 'Let\'s go!' -- Edit this bug report at https://bugs.php.net/bug.php?id=64844edit=1
Bug #64875 [Opn-Nab]: Fails if named parameters appears more than once
Edit report at https://bugs.php.net/bug.php?id=64875edit=1
ID: 64875
Updated by: u...@php.net
Reported by:zuohaocheng1022 at gmail dot com
Summary:Fails if named parameters appears more than once
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Mac OS X
PHP Version:5.5.0RC1
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Of course it fails. PDO just stinks: the core will replace :search with ?, then
pass it to MySQL which expects two values for two placeholders.
Can't work with the current PDO architecture. IMHO not a MySQL issue but yet
another bug in the PDO architecture: you can't mess around with query
manipulation at two layers that are logically seperated.
Previous Comments:
[2013-05-18 03:31:28] zuohaocheng1022 at gmail dot com
Description:
Pdo-mysql prepared statements execution fails when one named parameter appears
more than once in a SQL statement.
This problem will disappear if set PDO::ATTR_EMULATE_PREPARES to true.
Test script:
---
//CREATE TABLE `posts` (
// `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
// `name` VARCHAR(255),
// `body` TEXT
//);
$pdo-setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
// :search appears twice here
$stmt = $pdo-prepare('SELECT id FROM posts WHERE name LIKE :search OR body
LIKE :search');
$s = 'blablah';
$stmt-bindParam(':search', $s);
$stmt-execute(); // This step throws an exception: Error: SQLSTATE[HY093]:
Invalid parameter number
// $stmt-execute([':search'=$s]); will throw it too
$result = $stmt-fetch();
Expected result:
No exceptions.
Actual result:
--
$stmtexecute fails.
Error: SQLSTATE[HY093]: Invalid parameter number
--
Edit this bug report at https://bugs.php.net/bug.php?id=64875edit=1
Bug #64105 [Opn-Fbk]: Connection err dont work correctly
Edit report at https://bugs.php.net/bug.php?id=64105edit=1
ID: 64105
Updated by: u...@php.net
Reported by:giovanni dot cupini at tin dot it
Summary:Connection err dont work correctly
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: Debian - ver. Raspberry
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
I fail to parse this report, could someone help me understanding what's
requested?
All I get is that there is a combination which gives an internal server error
from the webserver:
if HOST option (2) and HOST option (4) and option (5) NOT WORK will output:
-
Host HTTP error 500
As far as I understand this is equivalent to the below sequence in which all
error messages are ignored, no proper error handling is done, a fatal error
gets thrown and script execution stops. Potentially giving 500 through
webserver...
/* Throws E_WARNING */
$mysqli = mysqli_connect(error, root, dolfomon, test);
var_dump(mysqli_connect_errno($mysqli));
/* Throws E_WARNING */
$res = mysqli_query($mysqli, SELECT 'Ok connection (PROC) width test ' AS _msg
FROM DUAL);
/* Throws E_FATAL */
$row = mysqli_fetch_assoc($res);
Due to the E_FATAL the OOP variant should never be executed. Sorry, I fail to
undertstand the report.
Previous Comments:
[2013-01-30 14:45:37] giovanni dot cupini at tin dot it
Description:
Msqli extension work correctly in procedural mode but NON work correctly width
mode OOP. EXEMPLE CODE:
?php
// FIRST CONNECTION Procedural
$mysqli = mysqli_connect(error, root, dolfomon, test); // HOST
(1)localhost (2)error
// ===INFO MySqli PHP ==
echo 'Current PHP version: ' . phpversion() . br;
echo 'MySqli Client library version: ' . mysqli_get_client_version() . br;
echo 'MySqli Server version: ' . mysqli_get_client_version() . br;
//===
if (mysqli_connect_errno($mysqli)) {
echo Connection failed (mode PROC) MySQL: . mysqli_connect_error()
.br;
}
echo br;
$res = mysqli_query($mysqli, SELECT 'Ok connection (PROC) width test ' AS _msg
FROM DUAL);
$row = mysqli_fetch_assoc($res);
echo $row['_msg'];
// second CONNECTION OOP
$my = new mysqli(error, root, dolfomon, test); // HOST (3)localhost
(4)error
// print_r($my); echo br; // (5) comment
(6) active statement
echo br;
if ($my-connect_errno) {
echo Connection failed (mode OOP) MySQL: . $my-connect_error;
}
echo br;
$res = $my-query(SELECT 'Ok connection (OOP) width test' AS _msg FROM DUAL);
$row = $res-fetch_assoc();
echo $row['_msg'];
?
Test script:
---
COMMENT:
if HOST option (1) and HOST option (3) and option (5) all OK it will output:
--
Current PHP version: 5.4.4-11
MySqli Client library version: 50528
MySqli Server version: 50528
Ok connection (PROC) width test
Ok connection (OOP) width test
--
If HOST option (2) and HOST option (4) and option (6) all OK it will output:
-
Current PHP version: 5.4.4-11
MySqli Client library version: 50528
MySqli Server version: 50528
Connection failed (mode PROC) MySQL: Unknown MySQL server host 'error' (20)
mysqli Object ( [affected_rows] = [client_info] = [client_version] = 50528
[connect_errno] = 2005 [connect_error] = Unknown MySQL server host 'error'
(20) [errno] = [error] = [error_list] = [field_count] = [host_info] =
[info] = [insert_id] = [server_info] = [server_version] = [stat] =
[sqlstate] = [protocol_version] = [thread_id] = [warning_count] = )
Connection failed (mode OOP) MySQL: Unknown MySQL server host 'error' (20)
if HOST option (2) and HOST option (4) and option (5) NOT WORK will output:
-
Host HTTP error 500
-
if HOST option (2) and HOST option (3) and option (5) Procedural work OK will
output:
---
Current PHP version: 5.4.4-11
MySqli Client library version: 50528
MySqli Server version: 50528
Connection failed (mode PROC) MySQL: Unknown MySQL server host 'error' (20)
Ok connection (OOP) width test
---
--
Edit this bug report at https://bugs.php.net/bug.php?id=64105edit=1
Bug #63530 [Opn]: mysqlnd_stmt::bind_one_parameter uses wrong alloc for stmt-param_bind
Edit report at https://bugs.php.net/bug.php?id=63530edit=1
ID: 63530
Updated by: u...@php.net
Reported by:geoff at lollywollydoodle dot com
Summary:mysqlnd_stmt::bind_one_parameter uses wrong alloc
for stmt-param_bind
Status: Open
Type: Bug
Package:MySQL related
Operating System: OS X 10.8.2
PHP Version:5.3.18
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Andrey, can you apply the patch? Looks fine to me.
Previous Comments:
[2012-11-15 18:34:11] geoff at lollywollydoodle dot com
Description:
This issue is specific to PDO, mysqlnd, PDO::ATTR_EMULATE_PREPARES = false,
and
PDO::ATTR_PERSISTENT = true.
When you run a prepared statement with parameters this way, PHP crashes.
My fix is essentially the same as the one for bug 61411 but just in a different
function. I browsed around git for at some other HEADs including master and it
looks like this issue is still there in all of them.
Test script:
---
$dbh = new PDO('mysql:host=' . DBHOST . ';dbname=' . DBDATA, DBUSER, DBPASS,
array(PDO::ATTR_EMULATE_PREPARES = false, PDO::ATTR_PERSISTENT
= true));
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$s = $dbh-prepare('select * from t where id = :id limit 1');
$s-execute(array(':id' = 1));
$r = $s-fetch(PDO::FETCH_ASSOC);
Expected result:
Script to not crash, result set to be available
Actual result:
--
PHP crashes (php-cgi or httpd process).
#0 0x7fff89a4a558 in malloc_error_break ()
#1 0x7fff89a4b912 in free ()
#2 0x00010a874c00 in _mysqlnd_pefree (ptr=0x103, persistent=1 '\001') at
mysqlnd_debug.c:1062
#3 0x00010a876107 in php_mysqlnd_stmt_free_stmt_content_pub
(s=0x7fdb94bf44d0) at mysqlnd_ps.c:2114
#4 0x00010a877023 in php_mysqlnd_stmt_net_close_priv (s=0x7fdb94bf44d0,
implicit=33 '!') at mysqlnd_ps.c:2209
#5 0x00010a875f6e in php_mysqlnd_stmt_dtor_pub (s=0x103, implicit=0 '\0')
at mysqlnd_ps.c:2236
#6 0x00010a756233 in pdo_mysql_stmt_dtor (stmt=0x10ae7f438) at
mysql_statement.c:64
#7 0x00010a7503a5 in free_statement (stmt=0x103) at pdo_stmt.c:2406
#8 0x00010a8f0041 in zend_objects_store_del_ref_by_handle_ex (handle=259,
handlers=0x10af16000) at zend_objects_API.c:220
#9 0x00010a8f00fa in zend_objects_store_del_ref (zobject=0x10b122100) at
zend_objects_API.c:173
#10 0x00010a8c46da in _zval_dtor [inlined] () at /Users/geoff/php-
5.3.17/Zend/zend_variables.h:35
#11 0x00010a8c46da in _zval_ptr_dtor (zval_ptr=0x103) at
zend_variables.h:447
#12 0x00010a9354dd in zend_leave_helper_SPEC (execute_data=0x103) at
zend_vm_execute.h:160
#13 0x00010a934b31 in execute (op_array=0x103) at zend_vm_execute.h:107
#14 0x00010a8c5af5 in zend_call_function (fci=0x7fff55971af8) at
zend_execute_API.c:969
#15 0x00010a8072f6 in zif_call_user_func_array (ht=259,
return_value=0x10b1214d0, return_value_ptr=0x1000, this_ptr=0x7fff8a0f45de,
return_value_used=0) at basic_functions.c:4814
#16 0x00010a934439 in zend_do_fcall_common_helper_SPEC (execute_data=0x103)
at zend_vm_execute.h:320
#17 0x00010a934b31 in execute (op_array=0x10b041508) at
zend_vm_execute.h:107
#18 0x00010a8c5af5 in zend_call_function (fci=0x7fff55971d98) at
zend_execute_API.c:969
#19 0x00010a8072f6 in zif_call_user_func_array (ht=184816904,
return_value=0x10b12a6e8, return_value_ptr=0x1000, this_ptr=0x7fff8a0f45de,
return_value_used=0) at basic_functions.c:4814
#20 0x00010a934439 in zend_do_fcall_common_helper_SPEC
(execute_data=0x10b041508) at zend_vm_execute.h:320
#21 0x00010a934b31 in execute (op_array=0x10b040fa0) at
zend_vm_execute.h:107
#22 0x00010a8cf878 in zend_execute_scripts (type=8, retval=0x7fff55972010,
file_count=1435967504) at zend.c:1236
#23 0x00010a87db02 in php_execute_script (primary_file=0x7fff559726b8) at
main.c:2308
#24 0x00010a949c90 in php_handler (r=0x10b040fa0) at sapi_apache2.c:669
#25 0x00010a28ee8d in ap_run_handler ()
#26 0x00010a28f592 in ap_invoke_handler ()
#27 0x00010a2c4e44 in ap_internal_redirect ()
#28 0x00010a5e2d65 in handler_redirect ()
#29 0x00010a28ee8d in ap_run_handler ()
#30 0x00010a28f592 in ap_invoke_handler ()
#31 0x00010a2c4efb in ap_process_request ()
#32 0x00010a2c1043 in ap_process_http_connection ()
#33 0x00010a2a40ad in ap_run_process_connection ()
#34 0x00010a2a465b in ap_process_connection ()
#35 0x00010a2ceeec in child_main ()
#36 0x00010a2cd99e in make_child ()
#37 0x00010a2cda50 in startup_children ()
#38 0x00010a2ccb1f in ap_mpm_run ()
#39 0x00010a297b12 in main ()
--
Edit this bug report at
Req #63958 [Opn-Wfx]: Fetch provides only strings with MySQL
Edit report at https://bugs.php.net/bug.php?id=63958edit=1
ID: 63958
Updated by: u...@php.net
Reported by:r dot schneider at artworx dot at
Summary:Fetch provides only strings with MySQL
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:PDO related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
From MySQL side: won't fix. As Johannes explained, there are two different
flavors of the MySQL protocol: text and binary. If using emulated PS, text
protocol is used, thus you get strings. This is how the server works.
From all I know, PDO spec don't require any alignment here.
Previous Comments:
[2013-01-14 08:04:42] r dot schneider at artworx dot at
Do you mean the meta data that I can obtain with getColumnMeta? I don't like to
use it as it is experimental.
If you look at this
http://stackoverflow.com/questions/5405813/php-selecting-from-mysql-and-receiving-th-data-types?lq=1
you see that I'm not the only one having this issue. But in this post someone
argues that PHP is weak typed. That means that it would be okay that the fetch
methods return string values when using MySQL. I think this behaviour could be
noted somewhere. I assume many people expect that the real data types will be
returned.
Can anyone give me an example or a link for a native prepared statment, please?
I'm still not sure what it really means. Thanks.
[2013-01-13 09:24:22] vincent at lycoops dot be
I don't get why you can't return the true data type. You have the result meta
data, so you can convert those types.
Setting the atrtibute ATTR_EMULATE_PREPARES should not be the only solution
(because it does not only have advantages).
[2013-01-10 15:47:08] r dot schneider at artworx dot at
What I have seen now: in
http://php.net/manual/en/mysqli-result.fetch-object.php it is stated that the
returned values will be of type string.
Maybe this should be stated in fetchObject (and other fetch methods) of PDO as
well.
[2013-01-10 15:41:56] r dot schneider at artworx dot at
What are native prepared statements? Do you mean stored procedures?
Let me ask in another way. How could an object easily gets populated with the
correct data types?
/** This class has the same/equivalent
data types as in an corresponding table */
class A {
/** @var int $id */
private $id;
/** @var string $name */
private $name;
/** @var float $size */
private $size;
/** @var DateTime $lastLogin */
private $lastLogin;
}
DateTime might be a bit more sophisticated. But the primitive data types should
get the right types. But this is not possible with fetchObject('A'). All member
variables will be strings.
Should fetchObject not be used that way? Should it be used only for fool data
classes (classes without methods)?
Or is this not the php style? Should I 'ignore' primitive data types? What
would mean fetchObject('A') is okay.
Or is it intended that fetchObject is only for 'string classes', or that the
call usually needs some rework?
Wouldn't it be good if we could get the correct data types?
Maybe it is my lack of knowledge. If so then sorry for the ticket. But I never
came across anywhere that told me that MySQL/PDO returns strings only and,
because of that, to use it in a certain way. That's why I suggested to put this
into the documentation.
Thank you!
[2013-01-10 14:57:17] johan...@php.net
How does this make the proper usage of fetchObject('myClass') not possible?
The reason is that the MySQL Server sends strings to PHP. PHP doesn't touch it
further. If you use native prepared statments (PDO uses an emulation by
default) MySQL switches to a different protocol and you get more native types
(while even that doesn't cover all types properly - thing MySQL DECIMAL, there
is no precise numeric type in PHP for non-integers)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63958
--
Edit this bug report at https://bugs.php.net/bug.php?id=63958edit=1
Bug #63886 [Opn]: PHP crashes when quoting string with PDO and using mysqlnd_ms
Edit report at https://bugs.php.net/bug.php?id=63886edit=1
ID: 63886
Updated by: u...@php.net
Reported by:rubs33 at gmail dot com
Summary:PHP crashes when quoting string with PDO and using
mysqlnd_ms
Status: Open
Type: Bug
-Package:mysqlnd_ms
+Package:MySQL related
Operating System: Fedora Linux 17 x86_64
PHP Version:5.5.0alpha2
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Hi,
this should be a follow up crash due to a mysqlnd bug. The connection is in an
invalid state. You should not be allowed to connect at all.
Albeit the charset is invalid, you can connect if using mysqlnd:
bash: /home/nixnutz/git/superhero/php-srcphp: Datei oder Verzeichnis nicht
gefunden
nixnutz@linux-0v4u:~/php-src/pecl/mysqlnd_ms/trunk php -d
mysqlnd.debug=d:t:O,/tmp/mysqlnd.trace -r '$pdo = new
PDO(mysql:host=127.0.0.1;port=3307;dbname=test;charset=x);
var_dump($pdo-quote(a));'
string(3) 'a'
ixnutz@linux-0v4u:~/php-src/pecl/mysqlnd_ms/trunk php -i | grep pdo
Configure Command = './configure' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--enable-debug'
'--disable-pear'
API Extensions = pdo_mysql,mysqli,mysql
pdo_mysql
pdo_mysql.debug = no value = no value
pdo_mysql.default_socket = /tmp/mysql.sock = /tmp/mysql.sock
However, if using libmysql one gets an error as I'd expect it:
nixnutz@linux-0v4u:~/php-src/pecl/mysqlnd_ms/trunk
/home/nixnutz/git/superhero/php-src/sapi/cli/php -d
mysqlnd.debug=d:t:O,/tmp/mysqlnd.trace -r '$pdo = new
PDO(mysql:host=127.0.0.1;port=3307;dbname=test;charset=x);
var_dump($pdo-quote(a));'
Character set 'x' is not a compiled character set and is not specified in the
'/home/nixnutz/ftp/mysql-5.6/install/share/charsets/Index.xml' file
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]
[2019] Can't initialize character set x (path:
/home/nixnutz/ftp/mysql-5.6/install/share/charsets/)' in Command line code:1
Stack trace:
#0 Command line code(1): PDO-__construct('mysql:host=127')
#1 {main}
thrown in Command line code on line 1
nixnutz@linux-0v4u:~/php-src/pecl/mysqlnd_ms/trunk
/home/nixnutz/git/superhero/php-src/sapi/cli/php -i | grep pdo
Configure Command = './configure' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd'
'--with-pdo-mysql=/home/nixnutz/ftp/mysql-5.6/install/bin/mysql_config'
'--enable-debug' '--disable-pear'
pdo_mysql
pdo_mysql.default_socket = /tmp/mysql.sock = /tmp/mysql.sock
pdo_sqlite
I'd say: Andrey, please have a look...
Ulf
PS: No mysqlnd package in select box?
Previous Comments:
[2013-01-02 19:20:00] rubs33 at gmail dot com
Description:
I am testing mysqlnd_ms plugin and I have just noticed that PHP crashes when I
use PDO::quote method at these conditions:
1 - Enable mysqlnd_ms
2 - At PDO constructor call, specify a host to a replicated database and
specify an invalid charset.
The plugin itself is working fine for its propose. The problem is with the
quote method, that might been affected by the plugin.
Versions:
PHP: 5.5.0alpha2
mysqlnd: 5.0.11-dev - 20120503
mysqlnd_ms: 1.4.2 (10402)
MySQL: 5.5.28
Note: when I run the test script with a non replicated database, I get the
expected result and PHP did not crash.
Test script:
---
?php
$pdo = new PDO('mysql:host=myapp;dbname=test;charset=x', 'rubens', '123');
$value = $pdo-quote('a');
var_dump($value);
?
Expected result:
string(3) 'a'
Actual result:
--
Segmentation fault (core dumped)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63886edit=1
Bug-Req #63466 [Opn]: PDO_MYSQL ignores PDO::FETCH_ORI_ABS in PDOStatement::fetch()
Edit report at https://bugs.php.net/bug.php?id=63466edit=1
ID: 63466
Updated by: u...@php.net
Reported by:vicrry at yahoo dot com dot hk
Summary:PDO_MYSQL ignores PDO::FETCH_ORI_ABS in
PDOStatement::fetch()
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package:PDO related
Operating System: CentOS
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
If its a bug, its a docs bug. Where in the PDO spec is written that every PDO
driver has to support random flags of other drivers? I do not remember anything
like that. Nonetheless the docs create the impression this is the case.
Previous Comments:
[2012-11-08 09:48:34] vicrry at yahoo dot com dot hk
Description:
When fetching with PDO::FETCH_ORI_ABS from MySQL with PDOStatement::fetch(),
the
driver silently swallows the options and work as if I passed
PDO::FETCH_ORI_NEXT.
Test script:
---
$stmt = $pdo-prepare('SELECT * FROM table', array(
PDO::ATTR_CURSOR = PDO::CURSOR_SCROLL
));
$stmt-execute();
$row = $stmt-fetch(PDO::FETCH_NUM, PDO::FETCH_ORI_ABS, 5);
Expected result:
The sixth row returned.
Actual result:
--
The first row returned.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63466edit=1
Bug #63386 [Opn-Nab]: mysqli_connect_error may not include username
Edit report at https://bugs.php.net/bug.php?id=63386edit=1 ID: 63386 Updated by: u...@php.net Reported by:mark at invisionpower dot com Summary:mysqli_connect_error may not include username -Status: Open +Status: Not a bug Type: Bug Package:MySQLi related Operating System: OS X 10.8.2 PHP Version:5.4.8 Block user comment: N Private report: N New Comment: This is not API related. This message comes from the server and is shown to you as-is. If you don't like it, please file a bug at bugs.mysql.com requesting the server to improve its error message. Previous Comments: [2012-10-29 16:15:56] mark at invisionpower dot com Description: If attempting to connect to a database using the MySQL Improved Extension using a username but a blank password, and that user does not exist, the error message does not specify the attempted username. See attached test script and expected/actual output. Test script: --- $mysqli = new mysqli( 'localhost', 'foo', '', 'dbname' ); echo $mysqli-connect_error; Expected result: Access denied for user 'foo'@'localhost' to database 'dbname' Actual result: -- Access denied for user ''@'localhost' to database 'dbname' -- Edit this bug report at https://bugs.php.net/bug.php?id=63386edit=1
Bug #63486 [Opn-Ver]: mysqli_free_result leave the resource variable in a messy state
Edit report at https://bugs.php.net/bug.php?id=63486edit=1
ID: 63486
Updated by: u...@php.net
Reported by:der...@php.net
Summary:mysqli_free_result leave the resource variable in a
messy state
-Status: Open
+Status: Verified
Type: Bug
Package:MySQLi related
PHP Version:5.4.8
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Thanks for the patch. It seems straight forward , however, it changes behaviour
in case of user errors. This makes me wonder in which PHP version it should go.
Current behaviour:
a) var_dump() - the XDebug view
res-free();
var_dump(res) -- throws a ton of warnings
b) Invalid property access - user error: why access free'd resource?
res-free();
var_dump(res-lengths) --- throws a ton of warnings
c) Invalid method access - user error: why access free'd resource?
res-free();
res-free(); --- trows a ton of warnings
In all three cases the user is confronted with warnings that he could ignore,
if he wanted. The patch leaves the user with:
a) var_dump() - the XDebug view
res-free()
var_dump(res) -- Warning on accessing free'd resource is gone
b)
res-free();
var_dump(res-lengths) -- Notice
var_dump(res) -- Warning gone
In sum: user gets less hints about his, well, why are you doing that-code.
c)
res-free();
res-free(); -- Fatal
Application that used to work now throws fatal
Please, note that I am not saying no to fixing the var_dump() issue. Trying to
explain the side effects of the proposed patch and asking what PHP version
would qualify for such a change.
Previous Comments:
[2012-11-15 17:17:16] u...@php.net
Derick, thanks a lot for the patch. All three of us MySQL guys are at a team
meeting. We will fly back home tomorrow morning. We can have a look once home
and no more tired (flight goes at 6:xx am).
[2012-11-11 12:53:01] der...@php.net
The following patch has been added/updated:
Patch Name: mysqli-clear-result-cleanup
Revision: 1352638381
URL:
https://bugs.php.net/patch-display.php?bug=63486patch=mysqli-clear-result-cleanuprevision=1352638381
[2012-11-11 12:52:02] der...@php.net
Description:
An Xdebug user filed the following report:
http://bugs.xdebug.org/view.php?id=900
I've just investigated this, and found out that this is something I can't fix
in Xdebug. mysqli_free_result() destroys the internal object, but leaves the
resource (in your case, $rs) in a silly state. All Xdebug does internally is
basically a var_dump( $rs ), and after it is freed with mysqli_free_result(),
that throws exactly the same error (without Xdebug). This can however, easily
be fixed in the MySQLi extension with the attached patch. The patch applies to
PHP 5.4, but this also a problem in master and PHP 5.3. It is also possible,
that other mysqli_free_* functions can benefit from a similar construct.
Test script:
---
?php
$con = mysqli_init();
mysqli_real_connect($con, '127.0.0.1', 'root', 'x');
$rs = mysqli_query($con, 'show schemas');
$row = mysqli_fetch_object($rs);
mysqli_free_result($rs);
echo hi mom;
var_dump( $rs );
?
Expected result:
The expected result is perhaps something like NULL (which my patch makes it
do).
Actual result:
--
hi mom
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
Bug #63486 [Opn]: mysqli_free_result leave the resource variable in a messy state
Edit report at https://bugs.php.net/bug.php?id=63486edit=1
ID: 63486
Updated by: u...@php.net
Reported by:der...@php.net
Summary:mysqli_free_result leave the resource variable in a
messy state
Status: Open
Type: Bug
Package:MySQLi related
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
Derick, thanks a lot for the patch. All three of us MySQL guys are at a team
meeting. We will fly back home tomorrow morning. We can have a look once home
and no more tired (flight goes at 6:xx am).
Previous Comments:
[2012-11-11 12:53:01] der...@php.net
The following patch has been added/updated:
Patch Name: mysqli-clear-result-cleanup
Revision: 1352638381
URL:
https://bugs.php.net/patch-display.php?bug=63486patch=mysqli-clear-result-cleanuprevision=1352638381
[2012-11-11 12:52:02] der...@php.net
Description:
An Xdebug user filed the following report:
http://bugs.xdebug.org/view.php?id=900
I've just investigated this, and found out that this is something I can't fix
in Xdebug. mysqli_free_result() destroys the internal object, but leaves the
resource (in your case, $rs) in a silly state. All Xdebug does internally is
basically a var_dump( $rs ), and after it is freed with mysqli_free_result(),
that throws exactly the same error (without Xdebug). This can however, easily
be fixed in the MySQLi extension with the attached patch. The patch applies to
PHP 5.4, but this also a problem in master and PHP 5.3. It is also possible,
that other mysqli_free_* functions can benefit from a similar construct.
Test script:
---
?php
$con = mysqli_init();
mysqli_real_connect($con, '127.0.0.1', 'root', 'x');
$rs = mysqli_query($con, 'show schemas');
$row = mysqli_fetch_object($rs);
mysqli_free_result($rs);
echo hi mom;
var_dump( $rs );
?
Expected result:
The expected result is perhaps something like NULL (which my patch makes it
do).
Actual result:
--
hi mom
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Couldn't fetch mysqli_result in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
Warning: var_dump(): Property access is not allowed yet in
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php on line 10
Call Stack:
0.0002 662616 1. {main}()
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:0
0.0032 672792 2. var_dump(class mysqli_result { public $current_field
= NULL; public $field_count = NULL; public $lengths = NULL; public $num_rows =
NULL; public $type = NULL })
/home/derick/dev/php/derickr-xdebug/tests/bug00900.php:10
class mysqli_result#2 (5) {
public $current_field =
NULL
public $field_count =
NULL
public $lengths =
NULL
public $num_rows =
NULL
public $type =
NULL
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63486edit=1
Req #50815 [Wfx]: Implement 323 short password hash fallback in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=50815edit=1 ID: 50815 Updated by: u...@php.net Reported by:jd at cpanel dot net Summary:Implement 323 short password hash fallback in mysqlnd Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: any PHP Version:5.3.1 Assigned To:mysql Block user comment: N Private report: N New Comment: I second Andrey: won't fix, http://sqlhack.com/ . Previous Comments: [2012-10-29 08:00:54] and...@php.net There is no such thing as discouraging. It is about updating the credentials, so they are more secure. Just use SET PASSWORD and hash the password again. [2012-10-26 17:18:09] toddr at cpanel dot net If you want to discourage use of the short password method, couldn't you just add a configure option to enable this and disable it by default? [2012-10-26 17:11:47] toddr at cpanel dot net If all MySQL 5 versions support this hashing scheme, Aren't you kinda overriding a user decision to enable short passwords on their MySQL server? It's also not clear when the failure happens what the problem is. [2010-08-27 06:00:08] ahar...@php.net Fix up the package to make this easier to search for. [2010-08-26 13:31:35] u...@php.net We mysql guys have no plans adding old insecure password stuff to mysqlnd. As it is assigned to us/me, I'm changing status to what shall be status from our/my perspective: won't fix. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=50815 -- Edit this bug report at https://bugs.php.net/bug.php?id=50815edit=1
Bug #62707 [Asn]: nextRowset causes segfault when using libmysql
Edit report at https://bugs.php.net/bug.php?id=62707edit=1
ID: 62707
Updated by: u...@php.net
Reported by:keithm at aoeex dot com
Summary:nextRowset causes segfault when using libmysql
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Here's a proper test:
--TEST--
Bug #62707 (nextRowset causes segfault when using libmysql)
--SKIPIF--
?php
require_once(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'skipif.inc');
require_once(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'mysql_pdo_test.inc');
MySQLPDOTest::skip();
$db = PDOTest::test_factory(dirname(__FILE__) . '/common.phpt');
$row = $db-query('SELECT VERSION() as _version')-fetch(PDO::FETCH_ASSOC);
$matches = array();
if (!preg_match('/^(\d+)\.(\d+)\.(\d+)/ismU', $row['_version'], $matches))
die(sprintf(skip Cannot determine MySQL Server version\n));
$version = $matches[0] * 1 + $matches[1] * 100 + $matches[2];
if ($version 5)
die(sprintf(skip Need MySQL Server 5.0.0+, found %d.%02d.%02d (%d)\n,
$matches[0], $matches[1], $matches[2], $version));
?
--FILE--
?php
require dirname(__FILE__) . '/mysql_pdo_test.inc';
$db = MySQLPDOTest::factory();
$db-setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db-exec('DROP PROCEDURE IF EXISTS p');
$db-exec('CREATE PROCEDURE p() BEGIN SELECT 1 AS one; SET @myvar = 1; SELECT
2 AS two, 3 AS three; END');
$stmt = $db-query(CALL p());
do {
var_dump($stmt-fetchAll(PDO::FETCH_ASSOC));
} while ($stmt-nextRowset());
var_dump($stmt-errorInfo());
$stmt = $db-query('SELECT 4 AS four');
var_dump($stmt-fetchAll(PDO::FETCH_ASSOC));
var_dump($stmt-errorInfo());
print done!;
?
--EXPECTF--
array(1) {
[0]=
array(1) {
[one]=
int(1)
}
}
array(1) {
[0]=
array(2) {
[two]=
int(2)
[three]=
int(3)
}
}
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
array(1) {
[0]=
array(1) {
[four]=
int(4)
}
}
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
done!
Previous Comments:
[2012-07-31 19:09:55] keithm at aoeex dot com
Description:
Using PDO with the MySQL driver built using libmysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.5.25a
After calling a stored procedure I have the following lines to eat up the
results before running more queries:
do { try { $queueStmt-fetch(); } catch (Exception $e){} } while ($queueStmt-
nextRowset());
When using libmysql this results in a segfault when calling nextRowset.
Test script:
---
?php
$db = new PDO('mysql:host=localhost;dbname=bugtest', 'bugtest', 'bugtest',
array(PDO::MYSQL_ATTR_INIT_COMMAND = SET NAMES utf8));
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db-setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sql = 'DROP TABLE IF EXISTS testtbl';
$db-exec($sql);
$sql = 'DROP PROCEDURE IF EXISTS testproc';
$db-exec($sql);
$sql = 'CREATE TABLE testtbl (pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY, data
VARCHAR(10), nextrun DATETIME)';
$db-exec($sql);
$sql = INSERT INTO testtbl (data, nextrun) VALUES ('asdf',
UTC_TIMESTAMP()),('defg', UTC_TIMESTAMP()),('higk', UTC_TIMESTAMP()),('lmnop',
UTC_TIMESTAMP());
$db-exec($sql);
$sql = 'CREATE PROCEDURE testproc() NOT DETERMINISTIC MODIFIES SQL DATA BEGIN
DECLARE nextId INT; SELECT pk INTO nextId FROM testtbl WHERE nextrun=(SELECT
MIN(nextrun) FROM testtbl) LIMIT 1; UPDATE testtbl SET
nextrun=UTC_TIMESTAMP()+INTERVAL 1 DAY WHERE pk=nextId; SELECT * FROM testtbl
WHERE pk=nextId; END';
$db-exec($sql);
$queueSql = 'CALL testproc()';
$queueStmt = $db-prepare($queueSql);
$queueStmt-execute();
$row=$queueStmt-fetch(PDO::FETCH_ASSOC);
do { try { $queueStmt-fetch(); } catch (Exception $e){} } while
($queueStmt-nextRowset());
echo Success;
Expected result:
Success
Actual result:
--
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=62707edit=1
Bug #62707 [Asn]: nextRowset causes segfault when using libmysql
Edit report at https://bugs.php.net/bug.php?id=62707edit=1
ID: 62707
Updated by: u...@php.net
Reported by:keithm at aoeex dot com
Summary:nextRowset causes segfault when using libmysql
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.5
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Your patch will unveil a leak. Workaround: don't use PDO, SP and libmysql. Go
mysqlnd.
Previous Comments:
[2012-10-26 09:27:08] u...@php.net
Here's a proper test:
--TEST--
Bug #62707 (nextRowset causes segfault when using libmysql)
--SKIPIF--
?php
require_once(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'skipif.inc');
require_once(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'mysql_pdo_test.inc');
MySQLPDOTest::skip();
$db = PDOTest::test_factory(dirname(__FILE__) . '/common.phpt');
$row = $db-query('SELECT VERSION() as _version')-fetch(PDO::FETCH_ASSOC);
$matches = array();
if (!preg_match('/^(\d+)\.(\d+)\.(\d+)/ismU', $row['_version'], $matches))
die(sprintf(skip Cannot determine MySQL Server version\n));
$version = $matches[0] * 1 + $matches[1] * 100 + $matches[2];
if ($version 5)
die(sprintf(skip Need MySQL Server 5.0.0+, found %d.%02d.%02d (%d)\n,
$matches[0], $matches[1], $matches[2], $version));
?
--FILE--
?php
require dirname(__FILE__) . '/mysql_pdo_test.inc';
$db = MySQLPDOTest::factory();
$db-setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db-exec('DROP PROCEDURE IF EXISTS p');
$db-exec('CREATE PROCEDURE p() BEGIN SELECT 1 AS one; SET @myvar = 1; SELECT
2 AS two, 3 AS three; END');
$stmt = $db-query(CALL p());
do {
var_dump($stmt-fetchAll(PDO::FETCH_ASSOC));
} while ($stmt-nextRowset());
var_dump($stmt-errorInfo());
$stmt = $db-query('SELECT 4 AS four');
var_dump($stmt-fetchAll(PDO::FETCH_ASSOC));
var_dump($stmt-errorInfo());
print done!;
?
--EXPECTF--
array(1) {
[0]=
array(1) {
[one]=
int(1)
}
}
array(1) {
[0]=
array(2) {
[two]=
int(2)
[three]=
int(3)
}
}
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
array(1) {
[0]=
array(1) {
[four]=
int(4)
}
}
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
done!
[2012-07-31 19:09:55] keithm at aoeex dot com
Description:
Using PDO with the MySQL driver built using libmysql
pdo_mysql
PDO Driver for MySQL = enabled
Client API version = 5.5.25a
After calling a stored procedure I have the following lines to eat up the
results before running more queries:
do { try { $queueStmt-fetch(); } catch (Exception $e){} } while ($queueStmt-
nextRowset());
When using libmysql this results in a segfault when calling nextRowset.
Test script:
---
?php
$db = new PDO('mysql:host=localhost;dbname=bugtest', 'bugtest', 'bugtest',
array(PDO::MYSQL_ATTR_INIT_COMMAND = SET NAMES utf8));
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db-setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$sql = 'DROP TABLE IF EXISTS testtbl';
$db-exec($sql);
$sql = 'DROP PROCEDURE IF EXISTS testproc';
$db-exec($sql);
$sql = 'CREATE TABLE testtbl (pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY, data
VARCHAR(10), nextrun DATETIME)';
$db-exec($sql);
$sql = INSERT INTO testtbl (data, nextrun) VALUES ('asdf',
UTC_TIMESTAMP()),('defg', UTC_TIMESTAMP()),('higk', UTC_TIMESTAMP()),('lmnop',
UTC_TIMESTAMP());
$db-exec($sql);
$sql = 'CREATE PROCEDURE testproc() NOT DETERMINISTIC MODIFIES SQL DATA BEGIN
DECLARE nextId INT; SELECT pk INTO nextId FROM testtbl WHERE nextrun=(SELECT
MIN(nextrun) FROM testtbl) LIMIT 1; UPDATE testtbl SET
nextrun=UTC_TIMESTAMP()+INTERVAL 1 DAY WHERE pk=nextId; SELECT * FROM testtbl
WHERE pk=nextId; END';
$db-exec($sql);
$queueSql = 'CALL testproc()';
$queueStmt = $db-prepare($queueSql);
$queueStmt-execute();
$row=$queueStmt-fetch(PDO::FETCH_ASSOC);
do { try { $queueStmt-fetch(); } catch (Exception $e){} } while
($queueStmt-nextRowset());
echo Success;
Expected result:
Success
Actual result:
--
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=62707edit=1
Bug #63347 [Asn]: Different behavior of parameters processing
Edit report at https://bugs.php.net/bug.php?id=63347edit=1
ID: 63347
Updated by: u...@php.net
Reported by:naquad at gmail dot com
Summary:Different behavior of parameters processing
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.8
Assigned To:wez
Block user comment: N
Private report: N
New Comment:
I consider this bogus: SQL syntax violated. Mapping feature abused to create
dynamic SQL, which is against the main argument brought up for PDO's PS
fixation.
Previous Comments:
[2012-10-25 04:01:44] larue...@php.net
seems native prepare supporting doesn't supports multi-same-name params, it
will
faild in the params number checking
[2012-10-24 14:06:31] naquad at gmail dot com
Description:
PDO::ATTR_EMULATE_PREPARES changes behavior of parameter processing.
When it is enabled multiple occurrences of named parameter work as expected,
but
when it is disabled I get Invalid parameter number error.
Test script:
---
?php
$pdo = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$pdo-setAttribute(PDO::ATTR_EMULATE_PREPARES, false); /// remove this line
and scirpt works as expected
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$query = $pdo-prepare('select :x = :x');
$query-bindValue(':x', 1);
$query-execute();
$t = $query-fetch();
var_dump($t);
$query-closeCursor();
Expected result:
array(2) {
'\'1\' = \'1\'' =
string(1) 1
[0] =
string(1) 1
}
Actual result:
--
PDOException: SQLSTATE[HY093]: Invalid parameter number in
/srv/http/fucktube/app/test.php on line 7
Call Stack:
0.0002 230552 1. {main}() /srv/http/fucktube/app/test.php:0
0.0739 246416 2. PDOStatement-execute()
/srv/http/fucktube/app/test.php:7
--
Edit this bug report at https://bugs.php.net/bug.php?id=63347edit=1
Bug #62426 [Opn-Nab]: mysqli_fetch_field_direct returns incorrect length on UTF8 fields
Edit report at https://bugs.php.net/bug.php?id=62426edit=1
ID: 62426
Updated by: u...@php.net
Reported by:robert dot butler at hoa-management dot com
Summary:mysqli_fetch_field_direct returns incorrect length
on UTF8 fields
-Status: Open
+Status: Not a bug
Type: Bug
Package:MySQLi related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Returns bytes
Previous Comments:
[2012-06-26 21:48:24] robert dot butler at hoa-management dot com
Description:
When using UTF8 in the database (mySQL 5.5.24-0ubuntu0.12.04.1), fields defined
as a certain length aren't returned as the correct length by
mysqli_fetch_field_direct. IOW, a char(32) field is shown as actually being 96
chars long because it's 32 * 3 (3 bytes per char instead of one).
The older mysql_field_len correctly reports the length.
Test script:
---
// Assuming a single table with a single field 'test' defined as char(32)
// and UTF-8 charset.
$connection = = mysqli_connect ('localhost', 'user', 'password');
$query = SELECT test FROM test_table LIMIT 1;
$result = mysqli_query ($connection, $query);
$field_info = mysqli_fetch_field_direct ($result, 0);
echo $field_info - length;
Actual result:
--
Returns 96; should be 32.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62426edit=1
Bug #62054 [Opn-Fbk]: Column size is not reserved for all UNION
Edit report at https://bugs.php.net/bug.php?id=62054edit=1
ID: 62054
Updated by: u...@php.net
Reported by:s-php at ertel-net dot de
Summary:Column size is not reserved for all UNION
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: Ubuntu
PHP Version:5.3.13
Block user comment: N
Private report: N
New Comment:
99% sure: Server bug, not a client issue.
Please, report column type information retrieved on the MySQL prompt when
preparing the statement using SQL PREPARE and then executing it. Log in to the
MySQL prompt using --column-type-info option to see the meta data reported by
the server.
Previous Comments:
[2012-05-17 13:28:21] s-php at ertel-net dot de
Description:
When I concatenate two queries with UNION an there are static strings in the
queries, mysqli only reserves a big enough variable for the strings in the
first query.
If there are static strings in the other queries after the UNION, the strings
are just cut off.
Test script:
---
$stmt = $this-mysqli-prepare(SELECT 'read' AS Action FROM tbl1
UNION
SELECT CASE status WHEN 0 THEN 'request-received' WHEN 1 THEN 'confirmed' WHEN
2 THEN 'x' END AS Action FROM tbl2);
$stmt-bind_result($action);
$stmt-execute();
while($stmt-fetch())
{
echo $action . ;
}
Expected result:
expected output is: read request-received confirmed
Actual result:
--
actual output is: read request-recei confirmed
The request-received is cut off!
--
Edit this bug report at https://bugs.php.net/bug.php?id=62054edit=1
Bug #62111 [Opn]: MySQL PDO memory leaks, when used own result row class
Edit report at https://bugs.php.net/bug.php?id=62111edit=1
ID: 62111
Updated by: u...@php.net
Reported by:hosiplan at gmail dot com
Summary:MySQL PDO memory leaks, when used own result row
class
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.4RC1
Block user comment: N
Private report: N
New Comment:
It matters a whole lot what the cause is. It is not a leak. First, it helps to
have some clean test code, such as this:
class pdo_row {
public function __construct($stmt) {
$stmt = NULL;
}
}
/* $pdo = new PDO(mysql:dbname=test;unix_socket=/var/run/mysql/mysql.sock,
root, ); */
$pdo = new PDO(sqlite::memory:);
$pdo-exec(DROP TABLE test);
$pdo-exec(CREATE TABLE test(id INT, col VARCHAR(200)));
for ($i = 0; $i 100; $i++) {
$pdo-exec(sprintf(INSERT INTO test(id, col) VALUES (1,
'012345678901234567890123456789012345678901234567890123456789-%d'), $i));
}
for ($i = 0; $i 10; $i++) {
$stmt = $pdo-prepare(SELECT col FROM test);
$stmt-execute();
$stmt-setFetchMode(PDO::FETCH_CLASS, 'pdo_row', array($stmt));
$rows = $stmt-fetchAll();
printf(emalloc %d kB, malloc %d kB\n,
memory_get_usage() / 1024,
memory_get_usage(true) / 1024);
}
Running the above for SQLlite gives me:
emalloc 205 kB, malloc 256 kB
emalloc 206 kB, malloc 512 kB
emalloc 207 kB, malloc 512 kB
emalloc 208 kB, malloc 512 kB
emalloc 209 kB, malloc 512 kB
emalloc 210 kB, malloc 512 kB
emalloc 211 kB, malloc 512 kB
emalloc 212 kB, malloc 512 kB
emalloc 213 kB, malloc 512 kB
emalloc 214 kB, malloc 512 kB
Running the above for MySQL gives me:
emalloc 221 kB, malloc 256 kB
emalloc 231 kB, malloc 512 kB
emalloc 240 kB, malloc 512 kB
emalloc 250 kB, malloc 512 kB
emalloc 259 kB, malloc 512 kB
emalloc 269 kB, malloc 512 kB
emalloc 278 kB, malloc 512 kB
emalloc 288 kB, malloc 512 kB
emalloc 297 kB, malloc 512 kB
emalloc 307 kB, malloc 512 kB
Second, it helps to understand the matter. In both cases emalloc() figures
increase, which is to be expected. PHP objects are created, the extensions
allocate memory using the PHP internal e*alloc() function family and the
figures increase. And, in both cases malloc() figures are the same.
No difference between MySQL and SQLite.
Previous Comments:
[2012-06-12 16:18:47] hosiplan at gmail dot com
I don't really care what you name it. It's a real problem and its eating my
memory and it shouldn't!
[2012-06-12 13:33:16] u...@php.net
There is no leak with MySQL. Memory usage increases, that's it.
==6216== LEAK SUMMARY:
==6216==definitely lost: 0 bytes in 0 blocks
==6216==indirectly lost: 0 bytes in 0 blocks
==6216== possibly lost: 0 bytes in 0 blocks
==6216==still reachable: 54 bytes in 2 blocks
==6216== suppressed: 0 bytes in 0 blocks
==6216== Rerun with --leak-check=full to see details of leaked memory
[2012-06-11 13:48:11] juzna dot cz at gmail dot com
The same causes PHP to crash completely on Windows 32bit with MSSQL server
(using
sqlsrv driver). I guess the root cause will be related.
[2012-05-22 20:39:55] juzna dot cz at gmail dot com
Leaks with mysql, no leaks with sqlite.
No need to fetchAll(); execute() is enough to get leaks
[2012-05-22 20:12:17] hosiplan at gmail dot com
affected version
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62111
--
Edit this bug report at https://bugs.php.net/bug.php?id=62111edit=1
Bug #62111 [Opn]: MySQL PDO memory leaks, when used own result row class
Edit report at https://bugs.php.net/bug.php?id=62111edit=1
ID: 62111
Updated by: u...@php.net
Reported by:hosiplan at gmail dot com
Summary:MySQL PDO memory leaks, when used own result row
class
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.4RC1
Block user comment: N
Private report: N
New Comment:
There is no leak with MySQL. Memory usage increases, that's it.
==6216== LEAK SUMMARY:
==6216==definitely lost: 0 bytes in 0 blocks
==6216==indirectly lost: 0 bytes in 0 blocks
==6216== possibly lost: 0 bytes in 0 blocks
==6216==still reachable: 54 bytes in 2 blocks
==6216== suppressed: 0 bytes in 0 blocks
==6216== Rerun with --leak-check=full to see details of leaked memory
Previous Comments:
[2012-06-11 13:48:11] juzna dot cz at gmail dot com
The same causes PHP to crash completely on Windows 32bit with MSSQL server
(using
sqlsrv driver). I guess the root cause will be related.
[2012-05-22 20:39:55] juzna dot cz at gmail dot com
Leaks with mysql, no leaks with sqlite.
No need to fetchAll(); execute() is enough to get leaks
[2012-05-22 20:12:17] hosiplan at gmail dot com
affected version
[2012-05-22 20:10:33] hosiplan at gmail dot com
Sorry, I've coppied wrong code
Test script:
---
$db = new PDO('mysql:host=127.0.0.1;dbname=information_schema', 'root',
'password');
class DbRow { public function __construct($stt = NULL) { } }
$begin = memory_get_usage();
for ($i=0; $i 10 ;$i++) {
$stt = $db-prepare(SELECT * FROM COLLATIONS);
$stt-setFetchMode(PDO::FETCH_CLASS, 'DbRow', array($stt));
$stt-execute();
$rows = $stt-fetchAll();
echo number_format((memory_get_usage() - $begin) / 100, 2, '.', '
'), MB\n;
}
[2012-05-22 20:05:25] hosiplan at gmail dot com
Description:
When PDO is told to use my row class and pass PDOStatement into it, it creates
cyclic reference, that prevents GC from deleting the row data, when not
required
anymore.
Test script:
---
$db = new PDO('mysql:host=127.0.0.1;dbname=information_schema', 'root',
'password');
class DbRow { public function __construct($stt = NULL) { } }
$begin = memory_get_usage();
for ($i=0; $i 10 ;$i++) {
$stt = $db-prepare(SELECT * FROM COLLATIONS);
$stt-setFetchMode(PDO::FETCH_CLASS, 'DbRow');
$stt-execute();
$rows = $stt-fetchAll();
echo number_format((memory_get_usage() - $begin) / 100, 2, '.', '
'), MB\n;
}
Expected result:
0.05 MB
0.05 MB
0.05 MB
0.05 MB
0.05 MB
0.05 MB
0.05 MB
0.05 MB
0.05 MB
0.05 MB
Actual result:
--
0.00 MB
0.05 MB
0.10 MB
0.14 MB
0.19 MB
0.24 MB
0.29 MB
0.34 MB
0.38 MB
0.43 MB
--
Edit this bug report at https://bugs.php.net/bug.php?id=62111edit=1
Req #61520 [Opn-Wfx]: Progress Report + Non-Blocking API
Edit report at https://bugs.php.net/bug.php?id=61520edit=1 ID: 61520 Updated by: u...@php.net Reported by:santec at riseup dot net Summary:Progress Report + Non-Blocking API -Status: Open +Status: Wont fix Type: Feature/Change Request Package:MySQL related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: There are currently no plans to support protocol extensions of MySQL forks inside mysqlnd. However, please note the extensive mysqlnd plugin API documentation. You may be able to accomplish support for arbitrary protocol extensions by developing a plugin yoursef. Asynchronous/non-blocking queries are available with mysqli, see mysqli_poll(). Previous Comments: [2012-03-26 18:44:20] santec at riseup dot net Description: MariaDB (MySQL fork) uses the MySQL protocol for connections, but supports at least 2 interesting features that can be used only with a client which support them: * Non-blocking operations: http://kb.askmonty.org/en/non-blocking-client-library * Progress report for long queries: http://kb.askmonty.org/en/progress-reporting I hope that mysqli/mysqlnd will add support for these features. I think that a client can support them without breaking support for MySQL. -- Edit this bug report at https://bugs.php.net/bug.php?id=61520edit=1
Bug #61411 [Opn-Csd]: PDO Segfaults with PERSISTENT == TRUE EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411edit=1
ID: 61411
Updated by: u...@php.net
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE
EMULATE_PREPARES == FALSE
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
-Assigned To:
+Assigned To:uw
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
http://news.php.net/php.cvs/68917
Previous Comments:
[2012-05-02 09:14:42] u...@php.net
Andrey,
do you think we should mnd_p*alloc(.., .., stmt-persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt-result_bind) {
1625andrey 289028 stmt-result_bind = mnd_ecalloc(stmt-field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt-result_bind = mnd_erealloc(stmt-result_bind,
stmt-field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
[2012-03-16 09:16:27] julien at palard dot fr
Description:
PDO Segfaults or hangs when a statement is executed with both ATTR_PERSISTENT
=
TRUE and ATTR_EMULATE_PREPARES = FALSE
The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that I
can't reproduce today, only the invalid pointer.
Playing with PERSISTENT and EMULATE_PREPARE with the given test script give :
| ATTR_PERSISENT | ATTR_EMULATE_PREPARES | WORKS |
| FALSE | FALSE |YES |
| FALSE | TRUE |YES |
| TRUE | FALSE | free() invalid pointer |
| TRUE | TRUE |YES |
Configure command :
./configure' '--enable-fpm' '--prefix=/usr/local/php-5.4.0'
'--enable-mbstring'
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl' '--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl' '--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3' '--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo' '--
without-pdo-sqlite' '--disable-phar' '--disable-posix' '--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'
Same bug reproduced in php 5.3.8 and php 5.3.10
Test script:
---
?php
$options = array(PDO::ATTR_PERSISTENT = TRUE,
PDO::ATTR_EMULATE_PREPARES = FALSE);
$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
'??', '??', $options);
$statement = $pdo-prepare(SELECT count(*) from a_table);
$statement-execute();
foreach ($statement as $line)
var_dump($line);
Expected result:
I expect PHP not to segfault
Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411edit=1
Bug #55334 [Asn]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334edit=1 ID: 55334 Updated by: u...@php.net Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:mattficken Block user comment: N Private report: N New Comment: So, this can be closed? Previous Comments: [2012-05-03 20:32:46] mattfic...@php.net johannes, your patch works for me with 5.4.1 on a 4-way and an 8-way windows 2008r2 server with: ab -n 1 -c 20 ab -n 10 -c 20 ab -n 10 -c 50 and ab -n 1 -c 50. [2012-05-02 09:47:14] johan...@php.net Matt, can you give it a new run. The change http://git.php.net/?p=php-src.git;a=commit;h=ea3e0d5a7370df63af9372780b91a749fda773b1 which is in 5.4.1 should fix the issue for 5.4. See also http://news.php.net/php.internals/59353 I wasn't able to see an issue neither in 5.3 nor 5.4 after having a 64-way Solaris machine running for a few hours. For Windows I did only a shorter test on a 4-way machine. [2012-04-08 22:19:22] ricardo dot nuno dot rodrigues at hotmail dot com Hi there, In PHP 5.4 TS VC9 (Win) I have the same problem. Under stress goes down. With file mysql_test.php: ?php mysqli_init(); ? Under: ab -n 1 -c 50 http://127.0.0.1/mysql_test.php It restart server (apache 2.2.21). Sometimes creates a delay. Under xdebug there's a big time to connect. Thanks Ricardo [2012-03-12 17:21:41] paj...@php.net Johannes, See last comment, I can also still reproduce it locally (dual quad). [2012-03-09 23:08:26] mattfic...@php.net To repro this problem, your test environment needs to have 4+ cpus, which the environment I was previously using didn't have. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334edit=1
Bug #55003 [Opn-Fbk]: PDO prepare() ignores MYSQL_ATTR_USE_BUFFERED_QUERY
Edit report at https://bugs.php.net/bug.php?id=55003edit=1
ID: 55003
Updated by: u...@php.net
Reported by:jamesvl+php at gmail dot com
Summary:PDO prepare() ignores MYSQL_ATTR_USE_BUFFERED_QUERY
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: all
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2011-06-06 20:15:09] jamesvl+php at gmail dot com
Description:
Steps to reproduce:
Set up a database so a query can return ~ 10,000 rows - enough to bump memory
usage to noticeable levels.
Use PDO to prepare a query where you explicitly disable buffered queries:
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = false. The PHP docs give an example of
how to do this at http://www.php.net/manual/en/ref.pdo-mysql.php.
Execute that statement.
Use memory_get_peak_usage() to watch PHP memory usage for the script before
and after the call to pdoStmt-execute().
Notes:
Settings PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to false when creating the PDO
object *does* work as expected. (i.e. query buffering will be turned off or on;
default is on if not specified)
However, the PHP documentation makes it appear that an individual prepared
statement should be able to change or override this settings for an individual
query, which is not the case.
PHP version tested: PHP 5.3.6 using mysqlnd, Win32 and Linux custom compile.
Note that testing on PHP 5.2 (i.e. without mysqlnd) is not possible since
mysqlib allocates memory outside of the PHP parser, and thus is not tracked by
memory_get_peak_usage() and is not limited by php.ini memory_limit settings.
Test script:
---
if ($this-db-getAttribute(PDO::ATTR_DRIVER_NAME) == 'mysql') {
$stmt = $this-db-prepare($qry,
array(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = false));
echo \nmax bytes mem used: . memory_get_peak_usage() . \n;
$stmt-execute();
echo max bytes mem used: . memory_get_peak_usage() . \n;
}
Expected result:
Expect to see:
Very little new memory allocated even when returning large result sets.
Memory usage should *not* vary based on the result set size.
ex:
max bytes mem used: 700624
max bytes mem used: 700624
Actual result:
--
Actually see:
Memory usage increases directly with the size of the result set returned - PDO
is using a buffered query.
ex:
max bytes mem used: 700240
max bytes mem used: 26291600
--
Edit this bug report at https://bugs.php.net/bug.php?id=55003edit=1
Req #54861 [Opn]: query() optionaly prepared and PDO::PARAM_FIELDNAME(quoting)
Edit report at https://bugs.php.net/bug.php?id=54861edit=1
ID: 54861
Updated by: u...@php.net
Reported by:harrieva at gmx dot de
Summary:query() optionaly prepared and
PDO::PARAM_FIELDNAME(quoting)
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
PDO::quote() places quotes around the *input string* (if required) and escapes
special characters within the input string, using a quoting style appropriate
to the underlying driver.
PDO has never been about aligning SQL differences. And, I also want to stress
out that MySQL does support the quoting you want,
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html#sqlmode_ansi_quotes
. It is *your* task to setup MySQL appropriately.
Previous Comments:
[2011-05-26 16:30:29] harrieva at gmx dot de
1. SQL-Quoting:
Postgresql whants a query like this: Select Name from Persons
Mysql wants the same query like this: Select `Name` from `Persons`
Mysql has a unique interpretation of the Standard by default. When i want to
write a query whitch runs on mysql and other sql-servers i have to quote
fielnames (and tablenames) diffrent. In my eyes this is something that should
be done by PDO-quote().
(This is importend for captalized fieldnames)
2. Queryparameter:
The second thing is an idea i had. This idea is on quoting to. Here is an
example:
How it is often done:
$sql = select * from a where bla = . $bla;
$res = $db-query($sql);
How it should be done:
$sql = select * from a where bla = . $db-quote($bla);
$res = $db-query($sql);
How should be done (the nicer way):
$stmt = $db-prepare(select * from a where bla = ?);
$stmt-execute($bla)
And now i like it to be done:
$stmt = $db-query(select * from a where bla = ?,$bla);
I like the ? and :-Syntax that i can use with prepared statements. And i like
to use this syntax in query() too. Like prepare(), query() returns a
PDO::Statement, so my idea is, that query() should return an executed prepared
statement, when a second parameter is given. It saves one line of code and it
feels smother, then getting an object back, call execute() for this object, and
then call fetchall() on the same object. Back in the days you mysql returnd
resultsets, and so people are still used to the thinking that db returns
results, The Statement-Objects are diffrent, but most people do not recordnice
it because they only use query(), Furthermore i think many people use prepare()
only when a sql is used more then one time. This is psychological, and so they
don't use the advantages of the ? and :-Syntax, because query() does not
support it...
I hope everything is clearer now ... ? ...
regards, Hendrik
[2011-05-26 14:54:26] johan...@php.net
I do not understand what you want. Could you be more precise please?
About the vs. ` thing: You can set the SQL mode in MySQL to be more standards
compliant. The MySQL developers are conservative in changing the default as it
will break many applications unfortunately.
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html (can be set per
session if you don't want/can change it globally)
[2011-05-19 13:33:54] harrieva at gmx dot de
Description:
I like prepared statements and its templating. Since query returns a statement,
why not making it a prepared one, when the second parameter is an array, and
execute it directly... Example: See my exPDO-Class at the bottom.
Since mysql quotes fieldnames(and tablenames) different then standardconform
sqlservers, it is not easy to write/generate sql that work everywhere... Eg.
postgre lowercases fieldnames when they are not quoted in ... Mysql wants `...
I help my self by deriving from PDO and overwrite quote...
public function quote($txt,$parameter_type = PDO::PARAM_STR ){
if($parameter_type == 12345){
if($this-getAttribute(PDO::ATTR_DRIVER_NAME) ==
'mysql'){
return '`' . $txt . '`';
}else{
return '' . $txt . '';
}
}else{
return parent::quote($txt,$parameter_type);
}
}
By the way: Here is my hole extention Now it is possible to see all the
executed querys, and the time it took to get the result
?php
class extPDO extends PDO{
public $query_count = 0;
public $exec_count = 0;
public $prepared_count = 0;
public $query_time = 0;
public $sqls = array();
Bug #61536 [Opn-Csd]: when building with hardening-wrapper, mysqlnd fails with format exceptions
Edit report at https://bugs.php.net/bug.php?id=61536edit=1 ID: 61536 Updated by: u...@php.net Reported by:i dot galic at brainsware dot org Summary:when building with hardening-wrapper, mysqlnd fails with format exceptions -Status: Open +Status: Closed Type: Bug Package:MySQL related Operating System: Ubuntu PHP Version:5.4.0 -Assigned To: +Assigned To:uw 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Duplicate of https://bugs.php.net/bug.php?id=60948 : [2012-02-01 13:10 UTC] ond...@php.net Description: $ svn diff Index: ext/mysqlnd/mysqlnd_wireprotocol.c === --- ext/mysqlnd/mysqlnd_wireprotocol.c (revision 322993) +++ ext/mysqlnd/mysqlnd_wireprotocol.c (working copy) @@ -500,7 +500,7 @@ const char * const msg = Authentication data too long. Won't fit into the buffer and will be truncated. Authentication will thus fail; SET_CLIENT_ERROR(*conn-error_info, CR_UNKNOWN_ERROR, UNKNOWN_SQLSTATE, msg); - php_error_docref(NULL TSRMLS_CC, E_WARNING, msg); + php_error_docref(NULL TSRMLS_CC, E_WARNING, %s, msg); DBG_RETURN(0); } Previous Comments: [2012-05-02 14:52:31] u...@php.net Funny compiler... const char * const msg = Authentication data too long. Won't fit into the buffer and will be truncated. Authentication will thus fail; SET_CLIENT_ERROR(*conn-error_info, CR_UNKNOWN_ERROR, UNKNOWN_SQLSTATE, msg); php_error_docref(NULL TSRMLS_CC, E_WARNING, %s, msg); DBG_RETURN(0); [2012-03-28 00:19:22] i dot galic at brainsware dot org Description: when building with hardening-wrapper, mysqlnd fails with format exceptions Test script: --- add CFLAGS=$CFLAGS -Werror=format-security Expected result: Everything builds happily. Actual result: -- php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c: In function âphp_mysqlnd_auth_writeâ: php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c:503:4: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors -- Edit this bug report at https://bugs.php.net/bug.php?id=61536edit=1
Bug #61837 [Opn]: Problem collecting stats with mysqlnd
Edit report at https://bugs.php.net/bug.php?id=61837edit=1
ID: 61837
Updated by: u...@php.net
Reported by:jpa...@php.net
Summary:Problem collecting stats with mysqlnd
Status: Open
Type: Bug
Package:MySQL related
Operating System: Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Memory statistics are not available on a per connection basis but only
globally. We need to update the documentation.
rows_fetched_from_client_normal_buffered are also only incremented on a global
level not on a per connection basis. This should be a bug, leaving it to Andrey
to decide and fix.
Previous Comments:
[2012-04-24 14:17:38] jpa...@php.net
Description:
mysqli_get_connection_stats() doesn't seem to work, but
mysqli_get_client_stats()
does.
mysqli_get_connection_stats() gives nearly no information at all, big part of
fields it returns are '0' valued
Test script:
---
ini_set('mysqlnd.collect_statistics', 1);
ini_set('mysqlnd.collect_memory_statistics', 1);
$db = mysqli_connect('server', 'user', 'secret', 'mydb');
$result = mysqli_query($db,SELECT user_id FROM users LIMIT 5);
mysqli_data_seek($result, 5);
$data = mysqli_fetch_row($result);
var_dump(mysqli_get_connection_stats($db));
Expected result:
I expect the keys mem_*** to contain non null values
rows_fetched_from_client_normal_buffered should be 1 as I fetch one value
from
a buffered non prepared dataset
Actual result:
--
array(160) {
[bytes_sent]=
string(3) 193
[bytes_received]=
string(3) 379
[packets_sent]=
string(1) 4
[packets_received]=
string(2) 12
[protocol_overhead_in]=
string(2) 48
[protocol_overhead_out]=
string(2) 16
[bytes_received_ok_packet]=
string(2) 11
[bytes_received_eof_packet]=
string(1) 9
[bytes_received_rset_header_packet]=
string(1) 5
[bytes_received_rset_field_meta_packet]=
string(3) 202
[bytes_received_rset_row_packet]=
string(2) 66
[bytes_received_prepare_response_packet]=
string(1) 0
[bytes_received_change_user_packet]=
string(1) 0
[packets_sent_command]=
string(1) 1
[packets_received_ok]=
string(1) 1
[packets_received_eof]=
string(1) 1
[packets_received_rset_header]=
string(1) 1
[packets_received_rset_field_meta]=
string(1) 2
[packets_received_rset_row]=
string(1) 6
[packets_received_prepare_response]=
string(1) 0
[packets_received_change_user]=
string(1) 0
[result_set_queries]=
string(1) 1
[non_result_set_queries]=
string(1) 0
[no_index_used]=
string(1) 0
[bad_index_used]=
string(1) 0
[slow_queries]=
string(1) 0
[buffered_sets]=
string(1) 1
[unbuffered_sets]=
string(1) 0
[ps_buffered_sets]=
string(1) 0
[ps_unbuffered_sets]=
string(1) 0
[flushed_normal_sets]=
string(1) 0
[flushed_ps_sets]=
string(1) 0
[ps_prepared_never_executed]=
string(1) 0
[ps_prepared_once_executed]=
string(1) 0
[rows_fetched_from_server_normal]=
string(1) 5
[rows_fetched_from_server_ps]=
string(1) 0
[rows_buffered_from_client_normal]=
string(1) 5
[rows_buffered_from_client_ps]=
string(1) 0
[rows_fetched_from_client_normal_buffered]=
string(1) 0
[rows_fetched_from_client_normal_unbuffered]=
string(1) 0
[rows_fetched_from_client_ps_buffered]=
string(1) 0
[rows_fetched_from_client_ps_unbuffered]=
string(1) 0
[rows_fetched_from_client_ps_cursor]=
string(1) 0
[rows_affected_normal]=
string(1) 0
[rows_affected_ps]=
string(1) 0
[rows_skipped_normal]=
string(1) 5
[rows_skipped_ps]=
string(1) 0
[copy_on_write_saved]=
string(1) 0
[copy_on_write_performed]=
string(1) 0
[command_buffer_too_small]=
string(1) 0
[connect_success]=
string(1) 1
[connect_failure]=
string(1) 0
[connection_reused]=
string(1) 0
[reconnect]=
string(1) 0
[pconnect_success]=
string(1) 0
[active_connections]=
string(1) 1
[active_persistent_connections]=
string(1) 0
[explicit_close]=
string(1) 0
[implicit_close]=
string(1) 0
[disconnect_close]=
string(1) 0
[in_middle_of_command_close]=
string(1) 0
[explicit_free_result]=
string(1) 0
[implicit_free_result]=
string(1) 0
[explicit_stmt_close]=
string(1) 0
[implicit_stmt_close]=
string(1) 0
[mem_emalloc_count]=
string(1) 0
[mem_emalloc_amount]=
string(1) 0
[mem_ecalloc_count]=
string(1) 0
[mem_ecalloc_amount]=
string(1) 0
[mem_erealloc_count]=
string(1) 0
[mem_erealloc_amount]=
string(1) 0
[mem_efree_count]=
string(1) 0
[mem_efree_amount]=
string(1) 0
[mem_malloc_count]=
string(1) 0
[mem_malloc_amount]=
string(1) 0
[mem_calloc_count]=
string(1) 0
[mem_calloc_amount]=
string(1) 0
[mem_realloc_count]=
string(1) 0
[mem_realloc_amount]=
string(1) 0
[mem_free_count]=
string(1) 0
Bug #55737 [Fbk-Nab]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio
Edit report at https://bugs.php.net/bug.php?id=55737edit=1
ID: 55737
Updated by: u...@php.net
Reported by:stefan dot kaifer at hartmann dot info
Summary:LOAD DATA LOCAL INFILE - The used command is not
allowed with this MySQL versio
-Status: Feedback
+Status: Not a bug
Type: Bug
Package:MySQL related
Operating System: opensuse 11.0
PHP Version:5.3.8
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
So, what is this report about? If it's on ext/mysql, I call it not a bug. Thus,
closing. If config is correct, things work just fine.
--
$host = localhost:/var/run/mysql/mysql.sock;
$user = root;
$pass = ;
$flags = 128;
$db = test;
printf(PHP %s\n, PHP_VERSION);
$file = getcwd() . DIRECTORY_SEPARATOR . foo.txt;
if (!($fp = fopen($file, w)))
die(sprintf(Failed to open '%s' for writing\n, $file));
if (!fwrite($fp, 1;a\n) || !fwrite($fp, 2;b\n))
die(sprintf(Failed to write to '%s'\n, $file));
fclose($fp);
$sql = sprintf(LOAD DATA LOCAL INFILE '%s' INTO TABLE test FIELDS TERMINATED
BY ';', $file);
if (!($mysql = mysql_connect($host, $user, $pass, true, $flags)))
die(sprintf(Failed to connect to MySQL\n));
printf(MySQL %s\n, mysql_get_server_info($mysql));
mysql_select_db($db);
mysql_query(DROP TABLE IF EXISTS test, $mysql);
mysql_query(CREATE TABLE test(id INT, col_a VARCHAR(255)), $mysql);
mysql_close($mysql);
if (!($mysql = mysql_connect($host, $user, $pass, true, $flags)))
die(sprintf(Failed to connect to MySQL\n));
if (!mysql_db_query($db, $sql, $mysql))
die(sprintf(LOAD DATA failed: %s\n, mysql_error($mysql)));
$res = mysql_query(SELECT * FROM test, $mysql);
while ($row = mysql_fetch_row($res))
var_dump($row);
gives -
PHP 5.3.12-dev
MySQL 5.5.16-log
array(2) {
[0]=
string(1) 1
[1]=
string(1) a
}
array(2) {
[0]=
string(1) 2
[1]=
string(1) b
}
Previous Comments:
[2012-02-02 14:55:26] stefan dot kaifer at hartmann dot info
Hi
sorry for the late answer: 5.3.4 worked for me, 5.3.4 to 5.3.7 I don't tested!
5.3.8 and 5.3.9 dont't works for me. I've compiled all versions with the same
configure-parameters.
I hope, that somebody can solve the problem.
Best reguards
Stefan
[2011-10-25 19:21:14] richardpq at gmail dot com
I haven't test this functionality before, this is the first time that I tested
it.
@Stefan point that it was working before and now not, but I don't know which
version he use... At the moment I am
Req #34906 [Asn-Wfx]: mysql: no way to get errno for a failed secondary connection attempt
Edit report at https://bugs.php.net/bug.php?id=34906edit=1
ID: 34906
Updated by: u...@php.net
Reported by:feldgendler at mail dot ru
Summary:mysql: no way to get errno for a failed secondary
connection attempt
-Status: Assigned
+Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: *
PHP Version:5CVS-2005-10-19 (cvs)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
It may be a valid feature request but meanwhile ext/mysql is in the process of
being softly deprecated. So, no feature additions for ext/mysql any more.
Security fixes, sure, feature additions, sorry, migrate to ext/mysqli.
Previous Comments:
[2011-02-16 12:07:29] johan...@php.net
The easy solution is to use mysqli without this default connection magic.
Making this work doesn't look trivial as these two cases have to work:
mysql_connect('localhost', 'valid', 'password');
mysql_connect('localhost', 'invalid', 'something');
mysql_query('invalid query');
echo mysql_error(); // should report the query error
as well as
mysql_connect('localhost', 'valid', 'password');
mysql_query('invalid query');
mysql_connect('localhost', 'invalid', 'something');
echo mysql_error(); // Should report the connect error
Assigning to mysql team
[2011-02-16 11:43:05] tony2...@php.net
Reassigned to Johannes.
The patch is still available here: http://dev.daylessday.org/diff/bug34906.diff
[2005-10-18 13:51:40] feldgendler at mail dot ru
About the patch: I think it's not enough. Once a connection attempt has failed,
conect_errno will be nonzero, and mysql_errno() without arguments always will
return this value. This will be too much deviation from the current behavior --
in fact, many always call mysql_errno() without arguments. Here is a typical
script which will be broken:
if (!mysql_connect('dbhost', 'user', 'pass')) {
mysql_connect('backup-dbhost', 'user', 'pass');
}
// ...
if (!mysql_query(...)) {
echo mysql_errno(); // This will print connect_errno!
}
I think that connect_errno should be reset to zero somewhere, but I don't know
where it would be appropriate. mysql_errno() shouldn't reset connect_errno
because mysql_error() and mysql_errno() are expected to be idempotent.
[2005-10-18 13:43:11] tony2...@php.net
Assigned to the maintainer.
Georg, please check the patch:
http://tony2001.phpclub.net/dev/tmp/bug34906.diff
[2005-10-18 13:19:52] feldgendler at mail dot ru
Description:
This is actually a bug in the well-defined and documented API, so there is no
reproduce code here.
After successfully establishing a connection, when an attempt to create another
connection fails, there is no way to find out the errno. This is because
mysql_errno() always uses an established link, either the one passed as the
argument or the default one. There is just no way to find out why the second
connection failed.
// assume this one succeeds
$first_connection = mysql_connect($host1, $u1, $p1);
// at this point, $first_connection is the default link
// assume this one fails
$second_connection = mysql_connect($host2, $u2, $p2);
// $second_connection is false,
// $first_connection is still the default link
echo mysql_errno();
// 0 is printed because there is no error
// on $first_connection
Before stamping Bogus on this bug, please note the following:
1. I have read the manual about mysql_errno() and mysql_connect(). Every word
of it. Even more, I think that PHP currently behaves as documented. But it's
just wrong because there is no way to find out why a connection has failed.
2. I have read other bug reports about mysql_errno(). They are actually about
other issues, or they don't state this problem clearly enough, so I'm filing
this bug report to make it clear what the problem is.
3. I have read the source code of the mysql extension. From the source, I've
found out that the error code and message from a failed connection attempt is
really stored in mysql_globals (connect_errno and connect_error), but
mysql_errno() PHP function only returns MySG(connect_errno) when the function
is invoked without arguments AND there is no default link. If there is a
default link, and an attempt to establish a second one has failed, there isn't
a way to have MySG(connect_errno) returned to the PHP program.
It is not obvious how to fix this bug, because it isn't a deviation from the
documented behavior, but rather an incompleteness of the API. Two of the
possible approaches
Bug #53970 [Opn-Nab]: PDOStatement::execute returns TRUE even when sql statement is not executed
Edit report at https://bugs.php.net/bug.php?id=53970edit=1
ID: 53970
Updated by: u...@php.net
Reported by:lopez at freshsite dot de
Summary:PDOStatement::execute returns TRUE even when sql
statement is not executed
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
There's no error when using MySQL defaults, just a warning.
See http://dev.mysql.com/doc/refman/5.6/en/server-sql-mode.html and set
sql_mode accordingly to get an error.
Previous Comments:
[2011-02-09 13:44:08] lopez at freshsite dot de
I recognized, that the error was different, but the expected result is same.
The sql statement tried to insert a too long string (6 chars) into a too small
field = varchar(2).
However, the execute function should return FALSE, but it doesn't !
[2011-02-09 12:04:13] lopez at freshsite dot de
Description:
I recognized, that the return value stay TRUE, even if the sql statement could
not be executed correctly.
Test script:
---
Example:
$sth = $this-db-prepare(REPLACE INTO test
SET bar =
:foo);
$error = $sth-execute(array('foo' = 'bar'));
/*
$error will be TRUE, because sql is correct and sent.
However, if the mysql user has not the rights (INSERT,DELETE) to do this, the
statement will be not executed at all without error message.
So, don't rely on the returning value until this is fixed!
Expected result:
$error should be FALSE
Actual result:
--
$error is TRUE
--
Edit this bug report at https://bugs.php.net/bug.php?id=53970edit=1
Bug #61196 [Opn-Fbk]: Unable to load dynamic library, undefined symbol
Edit report at https://bugs.php.net/bug.php?id=61196edit=1 ID: 61196 Updated by: u...@php.net Reported by:floren at yqed dot com Summary:Unable to load dynamic library, undefined symbol -Status: Open +Status: Feedback Type: Bug Package:Dynamic loading Operating System: CentOS 5.7 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: There seem to be multiple build targets in your script. Please, paste the one into a bug system comment that leads to the error. Thanks. Previous Comments: [2012-02-27 20:00:57] floren at yqed dot com Please note the --enable-mysqlnd, present into build() function. I'm forced to use it, or else the mysqli related functions are not available into phpinfo(). I obtain the same results, if I force to yes the PHP_MYSQLND_ENABLED variable: PHP_MYSQLND_ENABLED=yes export PHP_MYSQLND_ENABLED [2012-02-27 19:53:30] floren at yqed dot com Description: I compiled successfully PHP with the following configuration: http://pastie.org/3474406 Everything works as expected, except when I run PHP from command line. I was wondering if I missed something, thank you for your help. Test script: --- # php -r 'echo 1;' PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysql.so' - /usr/lib64/php/modules/mysql.so: undefined symbol: _mysqlnd_fetch_lengths in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_get_client_version in Unknown on line 0 PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=61196edit=1
Req #60716 [Opn]: Ability to set PDO connection timeout in milliseconds
Edit report at https://bugs.php.net/bug.php?id=60716edit=1 ID: 60716 Updated by: u...@php.net Reported by:markrose at markrose dot ca Summary:Ability to set PDO connection timeout in milliseconds Status: Open Type: Feature/Change Request Package:PDO related Operating System: n/a PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: For the MySQL part this can be considered Bogus/Not a bug because PHP is the wrong place to ask for it. Please, file a bug at MySQL. The underlying MySQL C API does not offer sub second granularity for setting the connect timeout. If it was to be fixed, it should be done at the lowest level which is the MySQL C API. No matter whether we are talking mysqlnd or MySQL Client Library (libmysql). See also http://dev.mysql.com/doc/refman/5.6/en/mysql-options.html and http://blog.ulf-wendel.de/?p=273 For the PDO part, I am not too keen of driver specific settings. What's the purpose of PDO if not providing an abstraction for it... However, for years now PDO seems kind of neglected, nobody feeling too much responsible for it. Previous Comments: [2012-01-11 17:20:38] markrose at markrose dot ca Description: I'd like the ability to set PDO's connection timeout (to MySQL specifically) in milliseconds. The lowest the timeout can current be set to is 1 second, which is an extremely long time to wait for a database machine to reply. I run a synchronously replicated MySQL environment (Galera), and I'd like to be able to move on to the next machine if the database doesn't respond in say, 10 ms. Instead, PHP waits one second. This reduces the throughput of my PHP scripts from several hundred per second to only a handful per second, severely impacting performance and quickly exhausting the PHP thread pool, leading to timeouts. -- Edit this bug report at https://bugs.php.net/bug.php?id=60716edit=1
Bug #61411 [Opn]: PDO Segfaults with PERSISTENT == TRUE EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411edit=1
ID: 61411
Updated by: u...@php.net
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE
EMULATE_PREPARES == FALSE
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Andrey,
do you think we should mnd_p*alloc(.., .., stmt-persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt-result_bind) {
1625andrey 289028 stmt-result_bind = mnd_ecalloc(stmt-field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt-result_bind = mnd_erealloc(stmt-result_bind,
stmt-field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
Previous Comments:
[2012-03-16 09:16:27] julien at palard dot fr
Description:
PDO Segfaults or hangs when a statement is executed with both ATTR_PERSISTENT
=
TRUE and ATTR_EMULATE_PREPARES = FALSE
The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that I
can't reproduce today, only the invalid pointer.
Playing with PERSISTENT and EMULATE_PREPARE with the given test script give :
| ATTR_PERSISENT | ATTR_EMULATE_PREPARES | WORKS |
| FALSE | FALSE |YES |
| FALSE | TRUE |YES |
| TRUE | FALSE | free() invalid pointer |
| TRUE | TRUE |YES |
Configure command :
./configure' '--enable-fpm' '--prefix=/usr/local/php-5.4.0'
'--enable-mbstring'
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl' '--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl' '--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3' '--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo' '--
without-pdo-sqlite' '--disable-phar' '--disable-posix' '--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'
Same bug reproduced in php 5.3.8 and php 5.3.10
Test script:
---
?php
$options = array(PDO::ATTR_PERSISTENT = TRUE,
PDO::ATTR_EMULATE_PREPARES = FALSE);
$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
'??', '??', $options);
$statement = $pdo-prepare(SELECT count(*) from a_table);
$statement-execute();
foreach ($statement as $line)
var_dump($line);
Expected result:
I expect PHP not to segfault
Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411edit=1
Bug #60930 [Opn-Nab]: PDO exec
Edit report at https://bugs.php.net/bug.php?id=60930edit=1 ID: 60930 Updated by: u...@php.net Reported by:lenzai2004-dev at yahoo dot fr Summary:PDO exec -Status: Open +Status: Not a bug Type: Bug Package:PDO related Operating System: Ubuntu 11.10 64bits PHP Version:5.3.9 Block user comment: N Private report: N New Comment: There is no bug here. Do as the message says and everything works fine. It is not possible to run another statement on a MySQL line prior to fetching the results. By default - as the message says - there is no implicit fetch of results. Thus, you must explicitly fetch them. Previous Comments: [2012-01-30 01:26:19] lenzai2004-dev at yahoo dot fr Description: SQL statement that return or should return a statement could leave an open cursor that cannot be closed. This bug is related to the following previous reports https://bugs.php.net/bug.php?id=36347 https://bugs.php.net/bug.php?id=34499 https://bugs.php.net/bug.php?id=42499 It's been reported that sql statement that do return result could cause this issue in non trivial situations. This report also highlight that statement returning empty result set could also cause the issue. Test script: --- $dbh = new PDO(mysql:your connection string, '', ''); echo $dbh-exec(SELECT * FROM cube where false); echo $dbh-exec(SELECT * FROM cube where false); print_r($dbh-errorInfo()); Expected result: 00 Actual result: -- 0Array ( [0] = HY000 [1] = 2014 [2] = Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO:: MYSQL_ATTR_USE_BUFFERED_QUERY attribute. ) -- Edit this bug report at https://bugs.php.net/bug.php?id=60930edit=1
Bug #60840 [Asn]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840edit=1 ID: 60840 Updated by: u...@php.net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs Status: Assigned Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) -Assigned To:uw +Assigned To:mysql Block user comment: N Private report: N New Comment: Don't assign to individuals if you mean mysql. Previous Comments: [2012-04-03 05:46:53] luiz dot fk at gmail dot com Hi... same here: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/lib64/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 [2012-01-22 20:02:35] public at grik dot net I tried to compile without mysqlnd driver: # cd ext/pdo_mysql # ./configure --with-pdo-mysql=/usr checking for mysql_config... /usr/bin/mysql_config # make; make install #php undefined symbol: mysqlnd_debug_std_no_trace_funcs same issue, even when mysqlnd is not used [2012-01-22 18:58:33] public at grik dot net Description: I built PHP 5.4 from sources in debug mode with pdo_mysql extension as shared, compiled successfully, but when I starting php I get the startup warning. My configure command: './configure' \ '--prefix=/usr/local' \ '--sysconfdir=/etc' \ '--with-config-file-path=/etc' \ '--with-mysql=shared,mysqlnd' \ '--with-mysqli=shared,mysqlnd' \ '--with-pdo-mysql=shared,mysqlnd' \ --enable-fpm \ --enable-debug Test script: --- just running from command line Actual result: -- # php Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so' - /usr/local/lib/php/extensions/debug-non-zts-20100525/pdo_mysql.so: undefined symbol: mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840edit=1
Bug #60665 [Opn]: call to empty() on NULL result using PDO::FETCH_LAZY returns false
Edit report at https://bugs.php.net/bug.php?id=60665edit=1
ID: 60665
Updated by: u...@php.net
Reported by:denaje at gmail dot com
Summary:call to empty() on NULL result using PDO::FETCH_LAZY
returns false
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux / Windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is not MySQL specific. Can be reproduced with SQLite.
$pdo = new PDO('sqlite::memory');
$statement = $pdo-prepare(SELECT NULL AS _something);
$statement-execute();
var_dump($row = $statement-fetch(PDO::FETCH_LAZY));
var_dump($row-_something);
var_dump(empty($row-_something));
$statement = $pdo-prepare(SELECT NULL);
$statement-execute();
var_dump($row = $statement-fetch(PDO::FETCH_ASSOC));
var_dump($row['_something']);
var_dump(empty($row['_something']));
Previous Comments:
[2012-01-05 14:56:35] denaje at gmail dot com
Description:
PHP 5.3.8 (on both Ubuntu Linux and Windows 7)
./configure --with-pdo-mysql
No changes to php.ini
When fetching rows from a MySQL database using PDO with the default fetch
method
FETCH_LAZY, the empty() function returns false on NULL values in the database.
This behavior does not exist when using other fetch methods (such as FETCH_OBJ
or
FETCH_ASSOC).
Test script:
---
$row = $stmt-fetch(PDO::FETCH_LAZY);
echo $row-Address2.\n; // RIGHT: outputs ''
var_dump($row-Address2); // RIGHT: outputs 'NULL'
var_dump(!$row-Address2);// RIGHT: outputs 'bool(true)'
var_dump(!!$row-Address2); // RIGHT: outputs 'bool(false)'
echo empty($row-Address2).\n; // WRONG: outputs ''
var_dump(empty($row-Address2)); // WRONG: outputs 'bool(false)'
var_dump(empty($row['Address2']));// WRONG: outputs 'bool(false)'
$var = $row['Address2'];
var_dump($var); // RIGHT: outputs 'NULL'
var_dump(empty($var));// RIGHT: outputs 'bool(true)'
Expected result:
NULL
bool(true)
bool(false)
1
bool(true)
bool(true)
NULL
bool(true)
Actual result:
--
NULL
bool(true)
bool(false)
bool(false)
bool(false)
NULL
bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60665edit=1
Bug #60515 [Opn]: Invalid parameter number although it is correct
Edit report at https://bugs.php.net/bug.php?id=60515edit=1
ID: 60515
Updated by: u...@php.net
Reported by:phoenixseve at freenet dot de
Summary:Invalid parameter number although it is correct
Status: Open
Type: Bug
Package:PDO related
Operating System: archlinux x86_64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
$stmt = $pdo-prepare(UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24');
Your SQL is invalid.
Whatever is behind, parsing is done by the PDO core. Thus, this is most
unlikely to be MySQL specific. Parsing needs to be done as a syntax is used
that is not supported by MySQL. Replace MySQL here with any other DB that does
not support named parameters or do the same with questionmarks and a DB that
does support named parameters only but no questionmarks.
Previous Comments:
[2012-03-06 02:35:34] jeffvanb at u dot washington dot edu
This misleading error message is also thrown when you include a single-line
comment that contains a single-quote.
Example:
SELECT something
-- This valid SQL syntax shouldn't be a problem
FROM somewhere
WHERE value = :v;
PDO will tell you the parameter count is mismatched and you will pull your hair
out wondering what is wrong.
[2011-12-13 20:57:47] phoenixseve at freenet dot de
Description:
When I execute the attached test script an exception is thrown with the message:
SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens
The exception is raised in the execute() line.
If you change the WHERE clause to `id`=24 there is no error message.
The same is true for this query: UPDATE `edtable` SET `id`=:p0 WHERE `id`='24'
The generated error message is obviously not correct. I don't even see why an
error message is generated as the request seems valid (although strange) to me.
Test script:
---
$createTableSql = 'EOT'
DROP TABLE IF EXISTS `edtable`;
CREATE TABLE IF NOT EXISTS `edtable` (
`id` bigint(20) NOT NULL,
`coun't()` varchar(20) NOT NULL
);
EOT;
$pdo = new PDO('mysql:host=localhost;dbname=aynte','aynte','aynte');
$pdo-setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$result = $pdo-query($createTableSql);
$result-closeCursor();
$stmt = $pdo-prepare(UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24');
$stmt-execute(array(':p0'='2', ':p1'='b2' ));
Expected result:
No error message.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens' in /srv/http/test.php:19\nStack trace:\n#0
/srv/http/test.php(19): PDOStatement-execute(Array)\n#1 {main}\n thrown in
/srv/http/test.php on line 19
--
Edit this bug report at https://bugs.php.net/bug.php?id=60515edit=1
Bug #61446 [Opn]: Can't prepare statement without getting a result
Edit report at https://bugs.php.net/bug.php?id=61446edit=1 ID: 61446 Updated by: u...@php.net Reported by:dasmag at gmail dot com Summary:Can't prepare statement without getting a result Status: Open Type: Bug Package:MySQLi related Operating System: ubuntu 11.04 PHP Version:5.3.10 -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: Very good find! Thanks! Andrey, mysqlnd sets an appropriate error message but we do not copy it into mysqli. mysqli has code for libmysql but not for mysqlnd. Maybe the copy was not needed for mysqlnd in the past? mysqlnd_stmt::prepare | info : stmt=0 | info : query=SELECT 2 | mysqlnd_conn_data::simple_command | | info : command=STMT_PREPARE ok_packet=13 silent=0 | | mysqlnd_conn_data::get_state | | mysqlnd_conn_data::get_state | | _mysqlnd_pestrdup | | | info : file=mysqlnd.c line= 326 | | | info : ptr=0x893d594 | | _mysqlnd_pestrdup | | info : adding error [Commands out of sync; you can't run this command now] to the list | | mysqlnd_conn_data::get_state | | mysqlnd_conn_data::get_state | | error: Command out of sync. State=4 | mysqlnd_conn_data::simple_command | info : FAIL mysqlnd_stmt::prepare mysqlnd_stmt::dtor Previous Comments: [2012-03-19 23:25:42] dasmag at gmail dot com Description: --- From manual page: http://www.php.net/mysqli.prepare --- There are an error if I heven't got a result from statement. Just execute the script with and without commented string. And there are no description in the documentation. Test script: --- ?php $mysqli = new mysqli(localhost); $st = $mysqli-prepare(SELECT 1); $st-execute(); // print_r($st-get_result()-fetch_assoc()); $st = $mysqli-prepare(SELECT 2); $st-execute(); ? Actual result: -- Fatal error: Call to a member function execute() on a non-objec -- Edit this bug report at https://bugs.php.net/bug.php?id=61446edit=1
Bug-Req #60849 [Opn]: Too many open links not reported correctly
Edit report at https://bugs.php.net/bug.php?id=60849edit=1 ID: 60849 Updated by: u...@php.net Reported by:haavard dot pedersen at gmail dot com Summary:Too many open links not reported correctly Status: Open -Type: Bug +Type: Feature/Change Request Package:MySQLi related Operating System: Linux PHP Version:5.3.9 Block user comment: N Private report: N New Comment: This is a bit on the API design/feature request side. mysqli.max_connections is a PHP setting. It is something enforced by the API. Because it does not come from the server side, the server logic does not set an error. There is no error on the line. Thus, the wrapped C API call, mysql_connect_errno() does not return one. Error: 1040 SQLSTATE: 08004 (ER_CON_COUNT_ERROR), Message: Too many connections must not be used to hint that mysqli.max_links has been exceeded. 1040 is a server error code. One needs a client error code, if at all. For example, Error: 2000 (CR_UNKNOWN_ERROR) Message: Unknown MySQL error could be used together with message pointing to the mysqli configuration. I say if at all because one also has to ask about the semantics of mysqli_connect_errno(). Previous Comments: [2012-01-23 12:25:15] haavard dot pedersen at gmail dot com Description: The Too many links error condition does not provide any error code. The only way you can get a description of the error is via the warning output. Run test script with mysqli.max_connections = 1 to see the problem. This even breaks the documentations example for mysqli_real_connect(). Test script: --- $link1 = mysqli_init(); $m_rc1 = mysqli_real_connect($link1, 'localhost', 'dbuser', 'dbpassword', 'testdb', 8889); echo --- Opening second link ---\n; $link2 = mysqli_init(); echo mysqli_init() result : .var_export($link2, TRUE).\n; echo --- Opening second connection ---\n; $m_rc2 = mysqli_real_connect($link2, 'localhost', 'dbuser', 'dbpassword', 'testdb', 8889); echo mysqli_real_connect() result : .var_export($m_rc2, TRUE).\n; echo Error number: .var_export(mysqli_connect_errno($link2), TRUE).\n; Expected result: An error number returned on the last line. Actual result: -- Error number is 0, possibly indicating success. -- Edit this bug report at https://bugs.php.net/bug.php?id=60849edit=1
Bug #61838 [Opn-Nab]: mysqli_get_cache_stats() does nothing
Edit report at https://bugs.php.net/bug.php?id=61838edit=1 ID: 61838 Updated by: u...@php.net Reported by:jpa...@php.net Summary:mysqli_get_cache_stats() does nothing -Status: Open +Status: Not a bug Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Good find, but... - it is marked as undocumented. Means, it can return pretty much anything, including nothing. - it is marked as deprecated. Whether this is sufficient or not, well, Docs team can decide on adding a note.I would say its OK as it is. Thus, setting to not a bug. Previous Comments: [2012-04-24 14:19:38] jpa...@php.net Description: mysqli_get_cache_stats() just return an empty array, always. It has not been implemented, but it's documented :) Test script: --- See source code of mysqli_get_cache_stats(), it always returns an empty array, whatever happens Expected result: mysqli_get_cache_stats() returns useful data Actual result: -- mysqli_get_cache_stats() is useless actually -- Edit this bug report at https://bugs.php.net/bug.php?id=61838edit=1
Bug #61536 [Opn]: when building with hardening-wrapper, mysqlnd fails with format exceptions
Edit report at https://bugs.php.net/bug.php?id=61536edit=1 ID: 61536 Updated by: u...@php.net Reported by:i dot galic at brainsware dot org Summary:when building with hardening-wrapper, mysqlnd fails with format exceptions Status: Open Type: Bug Package:MySQL related Operating System: Ubuntu PHP Version:5.4.0 Block user comment: N Private report: N New Comment: Funny compiler... const char * const msg = Authentication data too long. Won't fit into the buffer and will be truncated. Authentication will thus fail; SET_CLIENT_ERROR(*conn-error_info, CR_UNKNOWN_ERROR, UNKNOWN_SQLSTATE, msg); php_error_docref(NULL TSRMLS_CC, E_WARNING, %s, msg); DBG_RETURN(0); Previous Comments: [2012-03-28 00:19:22] i dot galic at brainsware dot org Description: when building with hardening-wrapper, mysqlnd fails with format exceptions Test script: --- add CFLAGS=$CFLAGS -Werror=format-security Expected result: Everything builds happily. Actual result: -- php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c: In function âphp_mysqlnd_auth_writeâ: php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c:503:4: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors -- Edit this bug report at https://bugs.php.net/bug.php?id=61536edit=1
Bug #61588 [Asn-Nab]: PDOStatement::getColumnMeta returns original table name from view
Edit report at https://bugs.php.net/bug.php?id=61588edit=1 ID: 61588 Updated by: u...@php.net Reported by:cdburgess at gmail dot com Summary:PDOStatement::getColumnMeta returns original table name from view -Status: Assigned +Status: Not a bug Type: Bug Package:PDO related Operating System: Mac OSX PHP Version:5.3.10 Assigned To:mysql Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Thank you for your report. You have hit an issue but this is not a PHP bug. Please, note the fine line between a PHP related bug and an issue with the MySQL database. Please, log in to MySQL using the MySQL command line client. Set the option --column-type-info for the command line client. This will make the MySQL prompt print the metadata reported by MySQL. Upon execution of: mysql SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, `MyInstall`.`script_id`, `MyInstall`.`path`, `MyInstall`.`url`, `MyInstall`.`created`, `MyInstall`.`version`, `MyInstall`.`admin_url`, `MyInstall`.`name`, `MyInstall`.`icon` FROM `my_installs` AS `MyInstall` where user_id = dc038c9e-7b4b-11e1-8397-60195b7d6275 ORDER BY `url` ASC; I see MySQL report the following meta data for the 3rd column (offset 2 in PDO): Field 3: `script_id` Catalog:`def` Database: `testpdo` Table: `MyInstall` Org_table: `scripts` Type: STRING Collation: utf8_general_ci (33) Length: 108 Max_length: 36 Decimals: 0 Flags: NO_DEFAULT_VALUE Adding a second condition to the WHERE clause does in fact change meta data as you report it. mysql SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, `MyInstall`.`script_id`, `MyInstall`.`path`, `MyInstall`.`url`, `MyInstall`.`created`, `MyInstall`.`version`, `MyInstall`.`admin_url`, `MyInstall`.`name`, `MyInstall`.`icon` FROM `my_installs` AS `MyInstall` where user_id = dc038c9e-7b4b-11e1-8397-60195b7d6275 and script_id = 057de1e0-7b48-11e1-8397-60195b7d6275 ORDER BY `url` ASC; Note the difference: Field 3: `script_id` Catalog:`def` Database: `testpdo` Table: `Script` Org_table: `scripts` Type: STRING Collation: utf8_general_ci (33) Length: 108 Max_length: 36 Decimals: 0 Flags: NOT_NULL PRI_KEY NO_DEFAULT_VALUE PART_KEY However, as this issue can be reproduced on the MySQL prompt one can be sure that there is no bug inside PHP. PHP does give you what MySQL reports. The correctness of the MySQL value itself should be checked by MySQL, not PHP. Please report a bug at mysql.com. Previous Comments: [2012-04-03 05:57:11] cdburgess at gmail dot com PHP v5.3.10 MySQL v5.5.22 Apache v2.2.21 Here is a script that contains all of the information you need to reproduce. The commented parts at the bottom contain all of the schema / data information. Just create your database, setup the PDO access, and run the script. It will provide the queries, descriptions, and getColumnMeta results to show you what I am seeing. Thanks! -- SCRIPT BELOW HERE -- ?php $connection = new PDO( 'mysql:host=localhost;dbname=testpdo', 'root', 'password' ); $query = select * from my_installs WHERE user_id = 'dcc87a2c-7b4b-11e1-8397- 60195b7d6275' and script_id = '057de1e0-7b48-11e1-8397-60195b7d6275' LIMIT 1; echo $query . 'br' . \n; echo 'In this query, you will see the table is reported as expected. (my_installs)'; $result = $connection-query($query); var_dump($result-getColumnMeta(2)); $query = SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, `MyInstall`.`script_id`, `MyInstall`.`path`, `MyInstall`.`url`, `MyInstall`.`created`, `MyInstall`.`version`, `MyInstall`.`admin_url`, `MyInstall`.`name`, `MyInstall`.`icon` FROM `my_installs` AS `MyInstall` WHERE `user_id` = 'dcc87a2c-7b4b-11e1-8397-60195b7d6275' ORDER BY `url` ASC; echo $query . 'br' . \n; echo 'With the Alias format of the query and using only the user_id in the where clause, the table Alias is reported.'; $result = $connection-query($query); var_dump($result-getColumnMeta(2)); $query = SELECT `MyInstall`.`id`, `MyInstall`.`user_id`, `MyInstall`.`script_id`, `MyInstall`.`path`, `MyInstall`.`url`, `MyInstall`.`created`, `MyInstall`.`version`, `MyInstall`.`admin_url`, `MyInstall`.`name`, `MyInstall`.`icon` FROM `my_installs` AS `MyInstall` WHERE `user_id` = 'dcc87a2c-7b4b-11e1-8397-60195b7d6275' AND
Bug #61516 [Opn]: PDOStatement::errorInfo returning NULL for driver code and message
Edit report at https://bugs.php.net/bug.php?id=61516edit=1
ID: 61516
Updated by: u...@php.net
Reported by:julien at palard dot fr
Summary:PDOStatement::errorInfo returning NULL for driver
code and message
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The PDO warning is based on a static look-up table compiled into the PDO core.
That means, it is out of control of any PDO driver. A SQL code reported by a
driver is translated into whatever message the PDO core likes.
Any PDO driver is free to provide an internal callback to update the contents
of the return value of errorInfo(). Providing an internal callback is not
mandatory.
Due to the different source of the error message one must not expect error
messages to be equal. At the end of the day: this is PDO...
Previous Comments:
[2012-03-26 16:49:00] julien at palard dot fr
Description:
While using not emulated prepared statement against MySQL 5.5, warnings (using
ERRMODE_WARNING) are more verbose than errorInfo(). With prepared queries,
errorInfo return (string, NULL, NULL).
This fact is true with or without ERRMODE_WARNING.
And this fact is also true, but different while using standard queries :
What the warning give me :
{{{
[WARNING] PDO::query() [a href='pdo.query'pdo.query/a]: SQLSTATE[23000]:
Integrity constraint violation: 1062 Duplicate entry '83-27
7727' for key 'UNIQUE'
}}}
What I got from errorInfo()[2] (Missing the Integrity constraint violation:
string, built client side from error code ?) :
{{{
Duplicate entry '83-277727' for key 'UNIQUE'
}}}
Test script:
---
?php
class My_PDOStatement extends PDOStatement
{
public function execute($input_parameters = NULL)
{
$res = parent::execute($input_parameters);
if ($res === FALSE)
var_dump($this-errorInfo());
return $res;
}
}
$options = array(PDO::ATTR_PERSISTENT = FALSE,
PDO::ATTR_ERRMODE = PDO::ERRMODE_WARNING,
PDO::ATTR_EMULATE_PREPARES = FALSE,
PDO::ATTR_DEFAULT_FETCH_MODE = PDO::FETCH_ASSOC,
PDO::ATTR_STATEMENT_CLASS = array('My_PDOStatement'));
$pdo = new PDO(...);
$stmt = $pdo-prepare(SELECT :a + :a);
$stmt-execute(array('a' = 1)); // Willingly generate 'Invalid parameter
number'
var_dump($stmt-fetchAll());
Expected result:
I Expect errorInfo() to return error messages.
Actual result:
--
errorInfo() in this specific case return (string, NULL, NULL).
--
Edit this bug report at https://bugs.php.net/bug.php?id=61516edit=1
Req #60354 [Asn]: MYSQL_CLIENT_COMPRESS in php.ini
Edit report at https://bugs.php.net/bug.php?id=60354edit=1 ID: 60354 Updated by: u...@php.net Reported by:spamik at yum dot pl Summary:MYSQL_CLIENT_COMPRESS in php.ini Status: Assigned Type: Feature/Change Request Package:MySQL related PHP Version:5.3.8 Assigned To:mysql Block user comment: N Private report: N New Comment: I do not agree on the statement developers write genuie applications. Native interfaces are there to get most out of a specific interface/library from a specific application. As there is no security concern or severe performance impact, developer shall have full control. There's no need to differ from the logic of the underlying C library to ensure somewhat consistent behaviour among the same family of interfaces/libraries of a specific vendor. Previous Comments: [2012-03-06 01:39:12] johan...@php.net I'm not sure I agree. For compression the developer should know what data to expect. Encryption should be configured alongside with host/user/password which usually happens in the application. Having more places overriding each others makes it hard to figure out which settings arebeing used in the end. [2011-11-22 03:02:50] spamik at yum dot pl Description: Using or not using mysql compression (or encryption) is a administrative decision, not decision that should be left for programmer as he usualy has no idea what is mysql configuration, what storage does it use and quite often this programmer just writes genuine aplications. default for compression in mysql client (MYSQL_CLIENT_COMPRESS) should be settable in php.ini http://pl2.php.net/manual/en/mysql.constants.php#mysql.client-flags This would also to permanent connections but You made it into two diffrent commands so it would be more difficult. -- Edit this bug report at https://bugs.php.net/bug.php?id=60354edit=1
Bug #36144 [Fbk-NoF]: only one row when using persistent connections and unbuffered queries
Edit report at https://bugs.php.net/bug.php?id=36144edit=1
ID: 36144
Updated by: u...@php.net
Reported by:php at kanariepiet dot com
Summary:only one row when using persistent connections and
unbuffered queries
-Status: Feedback
+Status: No Feedback
Type: Bug
Package:MySQL related
Operating System: Linux
PHP Version:5.1.2
Assigned To:mysql
Block user comment: N
Private report: N
Previous Comments:
[2010-11-02 17:31:49] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2007-01-04 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-12-27 23:43:33] and...@php.net
Do you still experience this behavior?
[2006-01-25 10:57:24] sni...@php.net
Assigned to the MySQL support.
[2006-01-24 15:30:13] php at kanariepiet dot com
Description:
Assume you have a webserver serving two PHP scripts. Both PHP
scripts use persistent MySQL database connections. Script one
uses normal mysql_query calls, script two uses
mysql_unbuffered_query calls.
Also, script one is doing additional mysql_query calls while
retrieving the records of the first mysql_query (yes, an sql
join would be better).
When script two (the one with mysql_unbuffered_query)
finishes, and script one reuses the persistent database
connection of script two, the resource identifier in script
one gets lost after the first loop, resulting in only one
returned row.
get_resource_type($res) should return 'mysql result', but will
return 'Unknown'
Reproduce code:
---
Script1.html:
$db = mysql_pconnect ('host', 'user', 'pass');
print ('We are using MySQL thread: '. mysql_thread_id() .'br /');
$res = mysql_query (SELECT * FROM temp.documents); // table with 1200 records
print ('mysql_num_rows() returned '. mysql_num_rows($res) .'br /');
while ($row = mysql_fetch_assoc ($res)) {
$res2 = mysql_query (SELECT * FROM temp.attachments WHERE document = .
$row['id']);
while ($row2 = mysql_fetch_assoc ($res2))
$row['attachments'][] = $row2;
$documents[] = $row;
}
print ('number of documents: '. count ($documents));
Script2.html:
$db = mysql_pconnect ('host', 'user', 'pass');
print ('We are using MySQL thread: '. mysql_thread_id() .'br /');
$res = mysql_unbuffered_query (SELECT * FROM temp.documents);
while ($row = mysql_fetch_assoc ($res)) {
}
Expected result:
Open script2.html and note the thread id.
Keep opening script1.html until the thread id is the same as
the one script2 used.
You should see this:
(script2.html)
We are using MySQL thread: 1439
(script1.html)
We are using MySQL thread: 1439
mysql_num_rows() returned 1200
number of documents: 1200
Actual result:
--
However, the output will be:
(script2.html)
We are using MySQL thread: 1439
(script1.html)
We are using MySQL thread: 1439
mysql_num_rows() returned 1200
number of documents: 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=36144edit=1
Req #39235 [Fbk-NoF]: Permit parameters in execute()
Edit report at https://bugs.php.net/bug.php?id=39235edit=1
ID: 39235
Updated by: u...@php.net
Reported by:mark dot 2391 at blueyonder dot co dot uk
Summary:Permit parameters in execute()
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package:MySQLi related
Operating System: Debian GNU/Linux
PHP Version:5.1.6
Assigned To:mysql
Block user comment: N
Private report: N
Previous Comments:
[2011-01-06 15:00:04] u...@php.net
What shall happen to bound parameters after the first execution (error or not)
of the statement? Shall mysqli try to use the same parameters for a new call to
execute even if no values are passed to the execute method?
stmt-execute(bound_values) - OK
stmt-execute() - reuse bound_values?
stmt-execute(bound_values) - error
stmt-execute() - reuse bound_values?
Or:
stmt-execute(bound_values) - OK
stmt-execute() - error: no values given
What shall happen if parameters have been bound but execute gets called with
new parameters:
stmt-bind(value) - use value
stmt-execute(another_value) - use another_value?
Or:
stmt-bind(value) - use value
stmt-execute(another_value) - error: must not mix syntax
Ulf
[2006-10-23 13:05:14] mark dot 2391 at blueyonder dot co dot uk
Description:
I want to convert to MySqli from PDO's MySql driver as I'm hitting a known bug
in PDO that isn't getting fixed and I figure MySqli would be faster anyway.
However, MySqli appears to be restrictive when compared to PDO in its
insistence that I use bind_params(). PDO allows the alternative to pass Mysql
parameters as an array to its execute() method.
My Mysql parameters are passed to me as an array in my code.
I do not know a way in PHP of passing an array of these parameters to MySQLi
while it insists on using bind_params which in turn insists on a fixed list of
named variables.
As I say, PDO copes with this as it's execute() method offers the alternative
choice while params to MySqli's execute() are marked as void, and so it seems
to me impossible to implement my Data Access Service layer (which manages DB
access on similar lines to the PHP SDO extension) with Mysqli at the moment
unless I completely lose the advantage of prepared statements.
The code below hopefully illustrates the kind of usage I need (and as I say,
PDO allows). Perhaps there is a workaround I have not thought of.
Thanks in advance for any comments/tips,
Mark
Reproduce code:
---
?php
// I propose this change to the mysqli_stmt_execute() syntax allowing me to do
something like the following:
// bool mysqli_stmt_execute ( mysqli_stmt stmt [string types, array
input_parameters] )
$dbh = new mysqli(localhost, my_user, my_password, world);
$sql = 'INSERT INTO TableA VALUES (?, ?)';
$mysqlParamsStringTypes = 'is';
$mysqlParams = array('1', 'a');
$myDasStmt = new MyDasStmt($dbh, $sql, $mysqlParamsStringTypes);
$myDasStmt-execute($mysqlParams);
class MyDasStmt
{
protected $mysqlParamsStringTypes;
protected $stmt;
public function __construct($dbh, $sql, $mysqlParamsStringTypes)
{
$this-stmt = $dbh-stmt_init();
$this-stmt-prepare($sql);
}
public function execute(array $mysqlParams)
{
$this-stmt-execute($this-mysqlParamsStringTypes, $mysqlParams);
// ...
}
}
?
Expected result:
N/A
Actual result:
--
N/A
--
Edit this bug report at https://bugs.php.net/bug.php?id=39235edit=1
Bug #41778 [Fbk-NoF]: Always get the SSL connection error
Edit report at https://bugs.php.net/bug.php?id=41778edit=1
ID: 41778
Updated by: u...@php.net
Reported by:mail at tobias-wassermann dot de
Summary:Always get the SSL connection error
-Status: Feedback
+Status: No Feedback
Type: Bug
Package:MySQLi related
Operating System: Windows XP
PHP Version:5.2.5
Assigned To:mysql
Block user comment: N
Private report: N
Previous Comments:
[2010-04-26 11:02:25] and...@php.net
Hi,
I see you use 5.2.5, can you try 5.3 with mysqlnd enabled, from snaps.php.net?
Thanks,
Andrey
[2010-04-24 21:41:09] extramobile at gmail dot com
When i connect like this:
$mysqli - ssl_set('client-key.pem', 'client-cert.pem', 'ca-cert.pem', null,
null );
(..)
$mysqli - real_connect( 'localhost', 'ssluser', 'sslpass', 'apps', 3306, null,
MYSQLI_CLIENT_SSL );
SHOW VARIABLES LIKE %SSL%;
returns nothing because of:
Warning: mysqli::real_connect() [function.mysqli-real-connect]: (HY000/2026):
SSL connection error in D:\web\xampp\htdocs\init\init.php on line 70
Warning: mysqli::query() [function.mysqli-query]: invalid object or resource
mysqli in D:\web\xampp\htdocs\init\init.php on line 72
But when I connect:
$mysqli - ssl_set('client-key.pem', 'client-cert.pem', 'ca-cert.pem' );
it gives me:
Warning: mysqli::ssl_set() expects exactly 5 parameters, 3 given in
D:\web\xampp\htdocs\init\init.php on line 59
Array ( [Variable_name] = have_openssl [Value] = YES )
Array ( [Variable_name] = have_ssl [Value] = YES )
Array ( [Variable_name] = ssl_ca [Value] = ca-cert.pem )
Array ( [Variable_name] = ssl_capath [Value] = )
Array ( [Variable_name] = ssl_cert [Value] = server-cert.pem )
Array ( [Variable_name] = ssl_cipher [Value] = )
Array ( [Variable_name] = ssl_key [Value] = server-key.pem )
i have xampp apache friends 1.6.4
I connect via CMD by
mysql --ssl-ca=ca-cert.pem --ssl-cert=client-cert.pem --ssl-key=client-key.pem
-ussluser -p
and SHOW VARIABLES LIKE %SSL%;
+---+-+
| Variable_name | Value |
+---+-+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca| ca-cert.pem |
| ssl_capath| |
| ssl_cert | server-cert.pem |
| ssl_cipher| |
| ssl_key | server-key.pem |
+---+-+
7 rows in set (0.00 sec)
[2008-11-10 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2008-11-02 12:47:00] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-04-22 20:01:24] mail at tobias-wassermann dot de
Hi,
reconstructed the case again - sorry for the delay - with the following code:
?php
error_reporting(E_ALL);
ini_set(display_errors, 1);
$conn = mysqli_init();
$conn-ssl_set(C:/proj/test/test.crt, C:/proj/test/ca.crt,
C:/proj/test/ca2.crt, NULL, NULL);
$conn-real_connect(www.iba-ag.com, user, pass, db, 3306, NULL,
MYSQLI_CLIENT_SSL);
echo $conn-errno;
$res = $conn-query(SELECT * FROM catalog);
echo - COUNT: {$res-num_rows};
?
The big BUT: Everytime I connect, I got a connection and the correct count of
the SELECT - it works if the ssl-files exists or not exists. So it seems to be
that never ever a ssl-connection will be established now - whats the problem?
I tried this with a 5.2.3 PHP on Windows and a 5.2.5 PHP on Linux - in both
cases with enabled OpenSSL-support
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=41778
--
Edit this bug report at https://bugs.php.net/bug.php?id=41778edit=1
Bug #48453 [Fbk-NoF]: fetch_assoc() problem
Edit report at https://bugs.php.net/bug.php?id=48453edit=1
ID: 48453
Updated by: u...@php.net
Reported by:gubbov53 at hotmail dot com
Summary:fetch_assoc() problem
-Status: Feedback
+Status: No Feedback
Type: Bug
Package:MySQLi related
Operating System: Windows Vista
PHP Version:5.2.9
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[2010-08-13 11:54:23] and...@php.net
Can you reproduce this with 5.3?
[2010-02-01 22:11:04] marco at marcoentertainment dot com
oh yeah i also got a syntax error in my for loop at , $i++) which went
away when a semicolon was added ie. $i++;)
i'm pretty tired so i prob missed something but still was odd
[2010-02-01 22:06:27] marco at marcoentertainment dot com
okay i wrote below with no sucess used the code from gubbov and it works as it
should :? when i used my code it seems like it didnt parse the for loop
properly but code after it was executed fine so ehhh but thanks gubbov
?php
$link = mysqli_connect(localhost,***,'**') or die;
mysqli_select_db($link, o**) or die;
if (mysqli_connect_errno()) {
echo 'Error: CNC';
exit;
}
$query = SELECT a.product_price, b.product_name, b.product_thumb_image,
c.category_id, a.product_id
FROM jos_vm_product_price AS a, jos_vm_product AS b,
jos_vm_product_category_xref AS c WHERE a.product_price = 100 AND a.product_id
= b.product_id AND c.product_id = a.product_id AND b.product_id = c.product_id
AND
b.product_publish = 'Y' ORDER BY a.product_price;
$result = mysqli_query($link, $query);
$num_results = mysqli_num_rows($result);
echo pNumber Found: .$num_results./p;
for ($i=0, $i $num_results; $i++) {
$row = mysqli_fetch_row($result);
echo p.($i+1).. Price: ;
echo ($row['product_price']);
echo /p;
}
mysqli_free_result($result);
mysqli_close($link);
?
[2009-08-12 14:09:49] mail at maiknowak dot de
php-code:
$sql=SELECT * FROM foo //causes Windows crash dialog or Apache crash
$sql=SELECT bar, baz FROM foo //works just fine
$result = $myMysql-query ( $sql );
$row = $result-fetch_assoc();
ver 5.2.10 5.3 shipped with Zend Studio 7
[2009-06-09 19:31:22] gubbov53 at hotmail dot com
A temp solution to have it working if you have code with fetch_assoc() is to
replace fetch_assoc() with fetch_fields() (to get keys), fetch_row() (to get
values), and array_combine(). See example below...
html
body
?php
@ $db=new mysqli('localhost','books_user','password','books_db');
if (mysqli_connect_errno()) {
echo Error: Could not connect to database. Please try again later.;
exit;
}
$query=select title,author from books where author like '%Morgan%';
$result=$db-query($query);
$num_results=$result-num_rows;
echo pNumber of books found: .$num_results./p;
$finfo = $result-fetch_fields(); $nc=0; foreach ($finfo as $val)
{$row_key[$nc++]=$val-name;} //---
for ($i=0; $i$num_results; $i++) {
//$row=$result-fetch_assoc();
$row_val=$result-fetch_row();$row=array_combine($row_key,$row_val); //---
echo pstrong.($i+1). Title: ;
echo htmlspecialchars(stripslashes($row['title']));
echo /strongbr /Author: ;
echo stripslashes($row['author']);
}
$result-free();
$db-close();
?
/body
/html
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=48453
--
Edit this bug report at https://bugs.php.net/bug.php?id=48453edit=1
Req #51147 [Fbk-Bgs]: mysql_connect can't resolve hostname within apache module
Edit report at https://bugs.php.net/bug.php?id=51147edit=1
ID: 51147
Updated by: u...@php.net
Reported by:kugel at rci dot rutgers dot edu
Summary:mysql_connect can't resolve hostname within apache
module
-Status: Feedback
+Status: Bogus
Type: Feature/Change Request
Package:MySQL related
PHP Version:5.2.12
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
There are no IP checks in libmysql.
Previous Comments:
[2010-05-11 12:55:04] paj...@php.net
Fedora 11 host, Apache/2.2.13 (Fedora) (from the report)
[2010-05-11 12:46:50] and...@php.net
Operating system?
[2010-02-25 18:25:20] kugel at rci dot rutgers dot edu
Description:
When this is run from the command line: php mytest.php on the local
machine, it connects successfully to the remote database. When it's
run as a webpage, it dies with the mysql_error message of Unknown
MySQL server host 'mysql.vobj.org' (2)
Command line access mysql -h mysql.vobj.org ... works fine.
If I substitute the IP address for the hostname, the webpage connects.
NOTE: vobj.org is hosted by dreamhost, and while mysql.vobj.org maps
to
67.205.28.132, 67.205.28.132 maps to thadison.masevo.dreamhost.com.
Maybe there's some IP security check that causes failure without
generating a useful error message.
Fedora 11 host, Apache/2.2.13 (Fedora)
Reproduce code:
---
?php
# $host='67.205.28.132';
$host='mysql.vobj.org';
$database='bugdemo';
$dbuser='bugdemo';
$pw='PHPisGreat';
$link = mysql_connect($host,$dbuser,$pw)
or die('Could not connect: ' . mysql_error() );
mysql_select_db($database) or die('Could not select database '.$database);
echo successful connectionbr /\n;
mysql_close($link);
?
Expected result:
Code should say successful connectionbr /\n
Actual result:
--
Could not connect: MySQL server host 'mysql.vobj.org' (2)
--
Edit this bug report at https://bugs.php.net/bug.php?id=51147edit=1
Bug #60119 [Asn-]: host=localhost lost in mysqlnd_ms_get_last_used_connection()
Edit report at https://bugs.php.net/bug.php?id=60119edit=1 ID: 60119 Updated by: u...@php.net Reported by:u...@php.net Summary:host=localhost lost in mysqlnd_ms_get_last_used_connection() -Status: Assigned +Status: To be documented Type: Bug Package:mysqlnd_ms PHP Version:Irrelevant -Assigned To:andrey +Assigned To:uw 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. Previous Comments: [2011-10-24 09:48:42] u...@php.net Description: mysqlnd_ms_get_last_used_connection() reports wrong host, if host is localhost. In that case, the host reported is . Test script: --- Tests in the repository fail, if configured appropriately. FAILED TEST SUMMARY - mysqlnd_ms_get_last_used_connection() [/home/nixnutz/php/php-src/pecl/mysqlnd_ms/trunk/tests/mysqlnd_ms_get_last_used_connection.phpt] mysqlnd_ms_get_last_used_connection() switching [/home/nixnutz/php/php-src/pecl/mysqlnd_ms/trunk/tests/mysqlnd_ms_get_last_used_connection_switches.phpt] Expected result: host=localhost not host= Actual result: -- host= -- Edit this bug report at https://bugs.php.net/bug.php?id=60119edit=1
Bug #60119 [-Opn]: host=localhost lost in mysqlnd_ms_get_last_used_connection()
Edit report at https://bugs.php.net/bug.php?id=60119edit=1 ID: 60119 Updated by: u...@php.net Reported by:u...@php.net Summary:host=localhost lost in mysqlnd_ms_get_last_used_connection() -Status: To be documented +Status: Open Type: Bug Package:mysqlnd_ms PHP Version:Irrelevant Assigned To:uw 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Documentation pushed. Will appear online shortly. Previous Comments: [2011-10-26 14:57:59] u...@php.net Automatic comment from SVN on behalf of uw Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318441 Log: Docs for bug #60119 [2011-10-26 14:18:11] u...@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-10-24 09:48:42] u...@php.net Description: mysqlnd_ms_get_last_used_connection() reports wrong host, if host is localhost. In that case, the host reported is . Test script: --- Tests in the repository fail, if configured appropriately. FAILED TEST SUMMARY - mysqlnd_ms_get_last_used_connection() [/home/nixnutz/php/php-src/pecl/mysqlnd_ms/trunk/tests/mysqlnd_ms_get_last_used_connection.phpt] mysqlnd_ms_get_last_used_connection() switching [/home/nixnutz/php/php-src/pecl/mysqlnd_ms/trunk/tests/mysqlnd_ms_get_last_used_connection_switches.phpt] Expected result: host=localhost not host= Actual result: -- host= -- Edit this bug report at https://bugs.php.net/bug.php?id=60119edit=1
Bug #59743 [Opn-Fbk]: doesn't install neither on os x or linux
Edit report at https://bugs.php.net/bug.php?id=59743edit=1 ID: 59743 Updated by: u...@php.net Reported by:sathia dot musso at gmail dot com Summary:doesn't install neither on os x or linux -Status: Open +Status: Feedback Type: Bug Package:mysqlnd_ms Operating System: Os x / linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Please, describe how you installed PHP: - what is your PHPs' configure line? - have you enabled mysqlnd? - have you installed PHP after the build? - which version of PHP are you using (several people reporting, thus double-checking)? This all smells like an incomplete installation. Thanks, Ulf Previous Comments: [2011-09-30 12:46:38] sathia dot musso at gmail dot com trying to install this extension on my dev server, but it fails consistently both via pecl and via manual installation. /usr/src/mysqlnd_ms- 1.1.0/ext/mysqlnd/mysqlnd_portability.h:40:46: fatal error: ext/mysqlnd/php_mysqlnd_config.h: No such file or directory this is the error, i tried to symlink the ext dir from the sources of my php version (5.3.8.1) but still it won't work. I was eager to try the lazy connections. any help on this? [2011-05-04 09:32:32] johannes at schlueters dot de Are you sure your PHP installation is using mysqlnd? (Check output of `php -m` or such which should list mysqlnd) [2011-05-02 14:29:06] sathia dot musso at gmail dot com it does work if you: root@host:/tmp/pear/temp/mysqlnd_ms# cp -a /usr/src/php- 5.3.6/ext/ . [2011-05-02 14:23:45] sathia dot musso at gmail dot com Description: Hi, I've tried a lot of combinations over different OS's but the error is always the same: /pecl install channel://pecl.php.net/mysqlnd_ms-1.0.1 [...] /tmp/pear/temp/mysqlnd_ms/php_mysqlnd_ms.c:28:33: fatal error: ext/mysqlnd/mysqlnd.h: No such file or directory compilation terminated. i was eager to try this extension, any idea how to fix it? thanks -- Edit this bug report at https://bugs.php.net/bug.php?id=59743edit=1
[PHP-BUG] Bug #55754 [NEW]: Only variables should be passed by reference for ZEND_SEND_PREFER_REF params
From: Operating system: PHP version: 5.3.8 Package: Scripting Engine problem Bug Type: Bug Bug description:Only variables should be passed by reference for ZEND_SEND_PREFER_REF params Description: Built-in functions where a parameter is defined with ZEND_SEND_PREFER_REF raises a Strict Standards warning if an expression is passed as the argument. The PREFER part signals the preference of passing by reference, but if the argument is not a variable, it should behave as if the parameter was defined with ZEND_SEND_BY_VAL and keep quiet, just as for regular ZEND_SEND_BY_VAL parameters. Test script: --- ?php error_reporting(32767); current($arr = array(0 = a)); /* Strict Standards: ... */ current(array(0 = a)); current($arr); ? Actual result: -- Strict Standards: Only variables should be passed by reference in filename on line 5 -- Edit bug report at https://bugs.php.net/bug.php?id=55754edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55754r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55754r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55754r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55754r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55754r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55754r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55754r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55754r=needscript Try newer version: https://bugs.php.net/fix.php?id=55754r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55754r=support Expected behavior: https://bugs.php.net/fix.php?id=55754r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55754r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55754r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55754r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55754r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55754r=dst IIS Stability: https://bugs.php.net/fix.php?id=55754r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55754r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55754r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55754r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55754r=mysqlcfg
Bug #55662 [Asn-Opn]: test script cause seg fault
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Updated by: u...@php.net
Reported by:larue...@php.net
Summary:test script cause seg fault
-Status: Assigned
+Status: Open
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
MySQL not PHP issue, http://bugs.mysql.com/?id=62350 .
Previous Comments:
[2011-09-12 11:38:04] larue...@php.net
Server version: 5.1.30 Source distribution, libmysql is also built from 5.1.30
[2011-09-12 11:33:10] and...@php.net
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
Bug #55662 [Asn-Bgs]: test script cause seg fault
Edit report at https://bugs.php.net/bug.php?id=55662edit=1
ID: 55662
Updated by: u...@php.net
Reported by:larue...@php.net
Summary:test script cause seg fault
-Status: Assigned
+Status: Bogus
Type: Bug
Package:MySQLi related
Operating System: Linux 64bit
PHP Version:5.4SVN-2011-09-10 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Server/libmysql issue.
Previous Comments:
[2011-09-12 13:02:32] u...@php.net
MySQL not PHP issue, http://bugs.mysql.com/?id=62350 .
[2011-09-12 11:38:04] larue...@php.net
Server version: 5.1.30 Source distribution, libmysql is also built from 5.1.30
[2011-09-12 11:33:10] and...@php.net
Hi,
can you provide me with info about the version of your MySQL Server and the
client library.
Thanks!
[2011-09-10 04:39:15] larue...@php.net
Description:
ext/mysqli/tests/mysqli_explain_metadata.phpt cause a segment fault(linked
against libmysql)
backtrace:
#0 0x00302af6ff20 in strlen () from /lib64/tls/libc.so.6
#1 0x007dbeb5 in add_property_string_ex (arg=0x2a99479160,
key=0xb68dec
catalog, key_len=8,
str=0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds,
duplicate=1)
at /home/huixc/opensource/php-src/trunk/Zend/zend_API.c:1561
#2 0x005f9a35 in php_add_field_properties (value=0x2a99479160,
field=0x1000410)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1060
#3 0x005f9d80 in zif_mysqli_fetch_fields (ht=1,
return_value=0x2a994bcf68, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /home/huixc/opensource/php-src/trunk/ext/mysqli/mysqli_api.c:1118
#4 0x0080e1b6 in zend_do_fcall_common_helper_SPEC
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:642
#5 0x0081491a in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x2a95fbc0e8)
at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:2215
#6 0x0080ceba in execute (op_array=0xff40d0) at
/home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410
#7 0x007d559c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1262
#8 0x0075698b in php_execute_script (primary_file=0x7fb230) at
/home/huixc/opensource/php-src/trunk/main/main.c:2388
#9 0x008f53f9 in do_cli (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983
#10 0x008f629a in main (argc=2, argv=0x7fb518) at
/home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356
f2,
(gdb) p *field
$2 = {name = 0x10007d0 possible_keys, org_name = 0x10007e0 , table =
0x10007c0 , org_table = 0x10007c8 , db = 0x10007b8 ,
catalog = 0x20200a3e6e6f6974 Address 0x20200a3e6e6f6974 out of bounds, def
=
0x0, length = 4096, max_length = 0,
name_length = 537542259, org_name_length = 1818311712, table_length =
1047748969, org_table_length = 762278761, db_length = 959789112,
catalog_length = 792474157, def_length = 1634298977, flags = 0, decimals =
31,
charsetnr = 8, type = MYSQL_TYPE_VAR_STRING,
extension = 0x61696c612f3c3130}
Test script:
---
ext/mysqli/tests/mysqli_explain_metadata.phpt
Expected result:
passed
Actual result:
--
seg fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=55662edit=1
Bug #55653 [Opn]: PS crash with libmysql when binding same variable as param and out
Edit report at https://bugs.php.net/bug.php?id=55653edit=1 ID: 55653 Updated by: u...@php.net Reported by:u...@php.net Summary:PS crash with libmysql when binding same variable as param and out Status: Open Type: Bug Package:MySQLi related PHP Version:5.4SVN-2011-09-09 (SVN) Block user comment: N Private report: N New Comment: Test added Previous Comments: [2011-09-09 12:11:54] u...@php.net Automatic comment from SVN on behalf of uw Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316455 Log: Bug #55653 [2011-09-09 12:00:27] u...@php.net Description: This will crash, if using mysqli with libmysql. sapi/cli/php -r '$link = new mysqli(192.168.2.27, root, , test); $stmt = $link-stmt_init(); $in = a; $stmt-prepare(SELECT ?); $stmt-bind_param(s, $in); $stmt-execute(); $stmt-bind_result($in); $stmt-fetch(); var_dump($in);' /home/nixnutz/php-src/branches/PHP_5_4/ext/mysqli/mysqli_api.c(890) : Block 0x071e5870 status: Invalid pointer: ((size=0x005976c6) != (next.prev=0x)) ==12847== Conditional jump or move depends on uninitialised value(s) ==12847==at 0x81C242: zend_mm_check_ptr (zend_alloc.c:1388) ==12847==by 0x81C230: zend_mm_check_ptr (zend_alloc.c:1385) ==12847==by 0x81DDA6: _zend_mm_free_int (zend_alloc.c:2064) ==12847==by 0x81F350: _efree (zend_alloc.c:2436) ==12847==by 0x5F412E: mysqli_stmt_fetch_libmysql (mysqli_api.c:890) Box 1: mysqli MysqlI Support = enabled Client API library version = 5.6.2-m5 Active Persistent Links = 0 Inactive Persistent Links = 0 Active Links = 0 Client API header version = 5.6.2-m5 MYSQLI_SOCKET = /tmp/mysql.sock Box 2: mysqli MysqlI Support = enabled Client API library version = 5.1.45 Active Persistent Links = 0 Inactive Persistent Links = 0 Active Links = 0 Client API header version = 5.1.45 MYSQLI_SOCKET = /tmp/mysql.sock Test script: --- sapi/cli/php -r '$link = new mysqli(192.168.2.27, root, , test); $stmt = $link-stmt_init(); $in = a; $stmt-prepare(SELECT ?); $stmt-bind_param(s, $in); $stmt-execute(); $stmt-bind_result($in); $stmt-fetch(); var_dump($in);' -- Edit this bug report at https://bugs.php.net/bug.php?id=55653edit=1
Bug #55558 [Opn-Wfx]: MySQL returns incorrect error message for test
Edit report at https://bugs.php.net/bug.php?id=8edit=1 ID: 8 Updated by: u...@php.net Reported by:simon at welsh dot co dot nz Summary:MySQL returns incorrect error message for test -Status: Open +Status: Wont fix Type: Bug Package:MySQL related Operating System: Mac OS 10.7 PHP Version:5.4SVN-2011-08-31 (SVN) Block user comment: N Private report: N New Comment: This is a MySQL server bug. Update to MySQL 5.5.15 and it's gone. If the test was not that strict, this MySQL server bug had never been found. Previous Comments: [2011-08-31 22:06:09] simon at welsh dot co dot nz Description: With MySQL 5.5.10-log (64 bit package, downloaded from mysql.com), if the user does not exist when connecting to the database, the error message returned is: Access denied for user 'rootunknown_real'@'localhost' (using password: NO) even when a password is supplied. This breaks both mysql_connect.phpt and mysql_pconnect.phpt in 5.4, as they are expecting the result to be (using password: YES). This also happens when running mysql from the command line, so the test should work around it. If the two test cases my patch changes should be testing for YES, instead of just an error, then change the connect/pconnect call to use $user rather than $user . 'unkown_real' -- Edit this bug report at https://bugs.php.net/bug.php?id=8edit=1
Bug #55283 [Ver]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections
Edit report at https://bugs.php.net/bug.php?id=55283edit=1 ID: 55283 Updated by: u...@php.net Reported by:aleksey at wepay dot com Summary:SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections Status: Verified Type: Bug Package:MySQLi related Operating System: Cent OS PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: PHP 5.4 beta is scheduled for next week. Is anybody working on fixing the underlying PHP Streams issue not only with 5.3 but also 5.4? Previous Comments: [2011-08-22 21:31:56] johan...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=315310 Log: - Revert r313616 (When we have a blocking SSL socket, respect the timeout option, scottmac) # This caused bug #55283, we should investigate a proper solution without # breaking anything. [2011-08-18 07:55:45] paj...@php.net You can try in German then as you both speak German as well. However it looks to me that the code speaks for itself. The connection fails after the timeout. This comment is based on this discussion on internals, http://news.php.net/php.internals/54667 . [2011-08-18 07:51:51] and...@php.net English is neither my mother tongue. [2011-08-18 07:17:15] spam2 at rhsoft dot net what try you to tell me with I don't get your comment :( remember that not everfybody has english as nmative language i need a way to revert this change to get PHP 5.3.7 working with mysqlnd/ssl the same way as it did the whole last year [2011-08-18 06:08:55] and...@php.net I don't get your comment :( The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55283 -- Edit this bug report at https://bugs.php.net/bug.php?id=55283edit=1
Bug #55536 [Opn-Bgs]: MySQLi fetch corrupting bound variables
Edit report at https://bugs.php.net/bug.php?id=55536edit=1
ID: 55536
Updated by: u...@php.net
Reported by:taopixdev at yahoo dot co dot uk
Summary:MySQLi fetch corrupting bound variables
-Status: Open
+Status: Bogus
Type: Bug
Package:MySQLi related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think the current behavior - setting bound result variables to NULL - OK .
Bound columns are explicitly mentioned as being modified when running a
prepared statement:
Binds columns in the result set to variables.
When mysqli_stmt_fetch() is called to fetch data, the MySQL client/server
protocol places the data for the bound columns into the specified variables
var1, , http://de2.php.net/manual/en/mysqli-stmt.bind-result.php
It is secondary if there is a result set or not. What's relevant in the above
is the fact that bound columns are set.
Setting to NULL in case of no result set makes perfectly sense. It means
setting (as documented) and setting to undefined (because of no result set).
Previous Comments:
[2011-08-30 10:31:05] taopixdev at yahoo dot co dot uk
Description:
I have tested this in different versions of PHP and it seems to be a bug from
version 5.3.0 onwards.
It seems that from PHP version 5.3.0 onwards that when a MySQL select statement
returns zero rows the bind result variable is being overwritten and set to a
null value.
In the example attached to this post I initialize a variable called $recordID
and set it to 0;
In versions of PHP prior to version 5.3.0 after the fetch has ran the $recordID
would still be set to 0 when zero rows are returned. However from versions
5.3.0 onwards the $recordID variable is overwritten and set to null.
Test script:
---
?php
$pID = 0;
$recordID = 0;
if ($stmt = $dbObj-prepare('SELECT `id`, `name` FROM MYTABLE WHERE id = ?)
{
if ($stmt-bind_param('i', $pID))
{
if ($stmt-bind_result($recordID, $name)
{
if ($stmt-execute())
{
$stmt-fetch();
}
}
}
}
?
Expected result:
In versions of PHP prior to version 5.3.0 after the fetch has ran the $recordID
would still be set to 0 when zero rows are returned.
Actual result:
--
From versions 5.3.0 onwards the $recordID variable is overwritten and set to
null.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55536edit=1
Bug #55001 [Asn-Bgs]: Mysql explain command with prepared statement
Edit report at https://bugs.php.net/bug.php?id=55001edit=1 ID: 55001 Updated by: u...@php.net Reported by:enrico dot triolo at gmail dot com Summary:Mysql explain command with prepared statement -Status: Assigned +Status: Bogus Type: Bug Package:MySQLi related Operating System: Ubuntu 11.04 PHP Version:Irrelevant Assigned To:mysql Block user comment: N Private report: N New Comment: Works fine with mysqlnd. That's a libmysql issue. Use mysqlnd instead. Because it works with mysqlnd, its not a mysqli issue either. Setting to Bogus as bugs.php.net is not for libmysql bug reports. Please, report over at bugs.mysql.com. -- script -- nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_4 cat foo.php ?php $sql = 'explain SELECT id FROM mytest_table WHERE idParent -1 AND idParent NOT IN ( SELECT id FROM mytest_table)'; $link = mysqli_connect(localhost, 'root', '', 'test'); $link-query(DROP TABLE IF EXISTS mytest_table); $link-query(CREATE TABLE mytest_table(id INT PRIMARY KEY NOT NULL, idParent INT)); $link-query(INSERT INTO mytest_table(id, idParent) VALUES (1, -1), (2, 1)); printf(Using prepared statement functions...\n); $stmt = mysqli_stmt_init($link); mysqli_stmt_prepare($stmt, $sql); mysqli_stmt_execute($stmt); mysqli_stmt_store_result($stmt); $result = mysqli_stmt_result_metadata($stmt); printf(Fields:\n); while($field = mysqli_fetch_field($result)) printf(\t%s(%d)\n, $field-name, $field-length); mysqli_free_result($result); mysqli_stmt_bind_result($stmt, $id, $select_type, $table, $type, $possible_keys, $key, $key_len, $ref, $rows, $extra); while(mysqli_stmt_fetch($stmt)) printf(Type field value: %s\n, $type); printf(\nUsing mysqli_query...\n); $result = mysqli_query($link, $sql); while($row = mysqli_fetch_array($result)) printf(Type field value: %s\n, $row['type']); mysqli_free_result($result); mysqli_close($link); -- libmysql - nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_4 sapi/cli/php -i | grep mysql Configure Command = './configure' '--with-mysql=/home/nixnutz/ftp/mysql-5.6.2-m5/install' '--with-mysqli=/home/nixnutz/ftp/mysql-5.6.2-m5/install/bin/mysql_config' '--with-pdo-mysql=/home/nixnutz/ftp/mysql-5.6.2-m5/install/bin/mysql_config' '--enable-debug' '--with-openssl' '--enable-pcntl' nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_4 sapi/cli/php foo.php Using prepared statement functions... Fields: id(3) select_type(19) table(64) type(10) possible_keys(4096) key(64) key_len(4096) ref(1024) rows(10) Extra(255) Type field value: ALL Type field value: unique_subq Using mysqli_query... Type field value: ALL Type field value: unique_subquery mysqlnd nixnutz@linux-fuxh:~/php/php-src/trunk sapi/cli/php foo.php Using prepared statement functions... Fields: id(3) select_type(19) table(64) type(10) possible_keys(4096) key(64) key_len(4096) ref(1024) rows(10) Extra(255) Type field value: ALL Type field value: unique_subquery Using mysqli_query... Type field value: ALL Type field value: unique_subquery nixnutz@linux-fuxh:~/php/php-src/trunk sapi/cli/php -i | grep mysqlnd Configure Command = './configure' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--enable-debug' '--enable-maintainer-zts' '--enable-pcntl' Previous Comments: [2011-06-08 08:48:20] enrico dot triolo at gmail dot com I'm using libmysql. Here's the output of the php --ri mysqli command: $php --ri mysqli mysqli MysqlI Support = enabled Client API library version = 5.1.54 Active Persistent Links = 0 Inactive Persistent Links = 0 Active Links = 0 Client API header version = 5.1.54 MYSQLI_SOCKET = /var/run/mysqld/mysqld.sock Directive = Local Value = Master Value mysqli.max_links = Unlimited = Unlimited mysqli.max_persistent = Unlimited = Unlimited mysqli.allow_persistent = On = On mysqli.default_host = no value = no value mysqli.default_user = no value = no value mysqli.default_pw = no value = no value mysqli.default_port = 3306 = 3306 mysqli.default_socket = no value = no value mysqli.reconnect = Off = Off mysqli.allow_local_infile = On = On [2011-06-08 02:17:22] johan...@php.net Are you using mysqlnd or libmysql. If libmysql which version? (check phpinfo() output or `php --ri mysqli` from command line) [2011-06-06 16:30:24] enrico dot triolo at gmail dot com Description:
Bug #55283 [Asn-Ver]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections
Edit report at https://bugs.php.net/bug.php?id=55283edit=1
ID: 55283
Updated by: u...@php.net
Reported by:aleksey at wepay dot com
Summary:SSL options set by mysqli_ssl_set ignored for MySQLi
persistent connections
-Status: Assigned
+Status: Verified
Type: Bug
Package:MySQLi related
Operating System: Cent OS
PHP Version:5.3.6
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Reproducible with PHP 5.3.7RC4-dev (cli) (built: Jul 26 2011 17:35:20) (DEBUG)
using *libmysql* to connect to 5.1.45-debug-log
Configure Command = './configure' '--with-mysql=mysqlnd'
'--with-mysqli=/usr/local/mysql/bin/mysql_config'
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--enable-debug'
'--enable-maintainer-zts' '--enable-mysqlnd-ms' '--enable-mysqlenterprise'
'--enable-mysqlnd-uh' '--enable-pcntl'
nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_3 sapi/cli/php bar.php
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(18) DHE-RSA-AES256-SHA
}
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(7) RC4-MD5
}
Previous Comments:
[2011-07-26 00:25:00] aleksey at wepay dot com
Please note that while the example shows the problem with the cipher, all other
parameters are also ignored. In particular, ssl cert info is critical.
[2011-07-26 00:20:58] aleksey at wepay dot com
Description:
The MySQLi ignores SSL options set with mysqli_ssl_set() for persistent
connections (works fine for non-persistent connections).
To reproduce:
1) Configure MySQL server with SSL support
(http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html)
2) Run the attached test script
Test script:
---
?
$host = 'localhost';
$user = 'root';
$pass = '';
$db= null;
$port = 3306;
$flags = MYSQLI_CLIENT_SSL;
/* persistent connection */
$link = mysqli_init();
mysqli_ssl_set($link, null, null, null, null, RC4-MD5);
if (mysqli_real_connect($link, 'p:' . $host, $user, $pass, $db, $port, null,
$flags)) {
$r = $link-query(SHOW STATUS LIKE 'Ssl_cipher');
var_dump($r-fetch_row());
}
/* non-persistent connection */
$link = mysqli_init();
mysqli_ssl_set($link, null, null, null, null, RC4-MD5);
if (mysqli_real_connect($link, $host, $user, $pass, $db, $port, null, $flags)) {
$r = $link-query(SHOW STATUS LIKE 'Ssl_cipher');
var_dump($r-fetch_row());
}
Expected result:
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(18) RC4-MD5
}
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(7) RC4-MD5
}
Actual result:
--
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(18) DHE-RSA-AES256-SHA
}
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(7) RC4-MD5
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55283edit=1
Bug #55283 [Ver]: SSL options set by mysqli_ssl_set ignored for MySQLi persistent connections
Edit report at https://bugs.php.net/bug.php?id=55283edit=1
ID: 55283
Updated by: u...@php.net
Reported by:aleksey at wepay dot com
Summary:SSL options set by mysqli_ssl_set ignored for MySQLi
persistent connections
Status: Verified
Type: Bug
Package:MySQLi related
Operating System: Cent OS
PHP Version:5.3.6
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
The actual issue here is in mysqlnd (or in the mysqli user API, however you put
it :-)): if using mysqli_init() to create a connection object we don't yet know
if it needs to be persistent or not. mysqli was changed to meet the needs of
mysqlnd. Unfortunately, this has an unforeseen side-effect on mysqli @ libmysql
[@ SSL]. Changing mysqli to make libmysql happy will cause leaks with mysqlnd.
This needs some think time.
Previous Comments:
[2011-08-05 11:53:47] u...@php.net
Reproducible with PHP 5.3.7RC4-dev (cli) (built: Jul 26 2011 17:35:20) (DEBUG)
using *libmysql* to connect to 5.1.45-debug-log
Configure Command = './configure' '--with-mysql=mysqlnd'
'--with-mysqli=/usr/local/mysql/bin/mysql_config'
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config' '--enable-debug'
'--enable-maintainer-zts' '--enable-mysqlnd-ms' '--enable-mysqlenterprise'
'--enable-mysqlnd-uh' '--enable-pcntl'
nixnutz@linux-fuxh:~/php/php-src/branches/PHP_5_3 sapi/cli/php bar.php
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(18) DHE-RSA-AES256-SHA
}
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(7) RC4-MD5
}
[2011-07-26 00:25:00] aleksey at wepay dot com
Please note that while the example shows the problem with the cipher, all other
parameters are also ignored. In particular, ssl cert info is critical.
[2011-07-26 00:20:58] aleksey at wepay dot com
Description:
The MySQLi ignores SSL options set with mysqli_ssl_set() for persistent
connections (works fine for non-persistent connections).
To reproduce:
1) Configure MySQL server with SSL support
(http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html)
2) Run the attached test script
Test script:
---
?
$host = 'localhost';
$user = 'root';
$pass = '';
$db= null;
$port = 3306;
$flags = MYSQLI_CLIENT_SSL;
/* persistent connection */
$link = mysqli_init();
mysqli_ssl_set($link, null, null, null, null, RC4-MD5);
if (mysqli_real_connect($link, 'p:' . $host, $user, $pass, $db, $port, null,
$flags)) {
$r = $link-query(SHOW STATUS LIKE 'Ssl_cipher');
var_dump($r-fetch_row());
}
/* non-persistent connection */
$link = mysqli_init();
mysqli_ssl_set($link, null, null, null, null, RC4-MD5);
if (mysqli_real_connect($link, $host, $user, $pass, $db, $port, null, $flags)) {
$r = $link-query(SHOW STATUS LIKE 'Ssl_cipher');
var_dump($r-fetch_row());
}
Expected result:
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(18) RC4-MD5
}
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(7) RC4-MD5
}
Actual result:
--
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(18) DHE-RSA-AES256-SHA
}
array(2) {
[0]=
string(10) Ssl_cipher
[1]=
string(7) RC4-MD5
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55283edit=1
Req #55152 [Asn-Bgs]: Mysql relative seek
Edit report at https://bugs.php.net/bug.php?id=55152edit=1
ID: 55152
Updated by: u...@php.net
Reported by:lenzai2004-dev at yahoo dot fr
Summary:Mysql relative seek
-Status: Assigned
+Status: Bogus
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:trunk-SVN-2011-07-06 (SVN)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Yes, that's the case. From our perspective ext/mysql should be maintenance
only. No feature additions as small as they may be. The recent initiative on
the internals lists has backed up our position.
Closing, won't add call to ext/mysql. Use mysqli or PDO_MySQL.
Previous Comments:
[2011-07-09 16:25:40] ka...@php.net
Hi
I believe the MySQL guys (namely Andrey, Ulf and Johannes) wants to only fix
bugs in the mysql module as the mysqli module was originally written to
deprecate the original mysql module one day.
I'll assign it to them so they can evaluate this report.
[2011-07-08 23:47:03] lenzai2004-dev at yahoo dot com
Yes Indeed.
Well if mysql API is considered deprecated in PHP 5 the I should drop my
request.
If not, I believe it is a nice a simple addition.
[2011-07-08 18:12:17] ka...@php.net
Hi, don't the mysqli module support this already, or with the MySQLi result
iterator from 5.4?
[2011-07-06 15:01:55] lenzai2004-dev at yahoo dot fr
Description:
There is currently a function to do absolute seek in Mysql API.
When you need to to relative seek , you have to implement integer counter to
keep track of the current cursor position. Then call seek
here is a sample code:
//iterating over rows
for/while{
mysql_fetch_();
$current_row++;
[...]
// call relative seek
$current_row+= $seek_offset;
mysql_data_seek($id, $current_row);
This quite simple but when the code gets complicated, it s easy to miss on
$current_row update. The only only solution is to encapsulate php mysql
function in additional abstraction layer to handle counter updates safely.
I suppose the internal counter is already available in mysql module.
What I am suggesting, is to expose this internal counter by adding a new
function to mysql API.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55152edit=1
Bug #55067 [Opn]: MySQL doesn't support compression
Edit report at https://bugs.php.net/bug.php?id=55067edit=1 ID: 55067 Updated by: u...@php.net Reported by:belov1985 at gmail dot com Summary:MySQL doesn't support compression Status: Open Type: Bug Package:MySQLi related Operating System: FreeBSD 8.2 PHP Version:5.3.6 -Assigned To: +Assigned To:ahristov Block user comment: N Private report: N New Comment: Andrey, can you have a look? You've been the last one working on the config9.m4. Seems buggy. Previous Comments: [2011-06-29 09:46:55] belov1985 at gmail dot com Description: Version mysqlnd 5.0.8-dev - 20102224 - $Revision: 308673 $ Compression not supported PHP build info: ./configure --with-layout=GNU --localstatedir=/var --with-config-file-scan-dir=/usr/local/etc/php --disable-all --enable-libxml --with-pcre-regex=/usr/local --with-zlib-dir=/usr --program-prefix= --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-mcrypt --with-curl --with-jpeg-dir=/usr/local/lib/ --with-freetype-dir=/usr/local/include/freetype2/ --with-png-dir=/usr/local/lib/ --with-iconv-dir=/usr/local/lib --with-libxml-dir=/usr/local/include/ --with-libxml-dir=/usr/local --with-gd --with-bz2 --with-pcre-regex --with-iconv --with-ttf --with-zlib --with-sqlite3 --enable-session --enable-json --enable-gd-native-ttf --enable-inline-optimization --enable-mbstring --enable-xml --enable-dom --enable-simplexml --enable-fpm --with-fpm-user=www --with-fpm-group=www --with-regex=php --with-zend-vm=CALL --disable-ipv6 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ Some strange info i get, when do ./configure --help --disable-mysqlnd-compression-support Enable support for the MySQL compressed protocol in mysqlnd :) -- Edit this bug report at https://bugs.php.net/bug.php?id=55067edit=1
Bug #54978 [Opn-Fbk]: mysql_query() returns true with a SELECT statement
Edit report at https://bugs.php.net/bug.php?id=54978edit=1
ID: 54978
Updated by: u...@php.net
Reported by:radu dot dineiu at gmail dot com
Summary:mysql_query() returns true with a SELECT statement
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQL related
Operating System: Any
PHP Version:5.3.6
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Are you using libmysql, if so, which version? Can you reproduce with mysqlnd?
And, yes, looks like we need the patch. I wonder if its libmysql version
dependent.
Thanks!
Previous Comments:
[2011-06-02 17:38:28] radu dot dineiu at gmail dot com
Description:
This doesn't happen often, but it does happen sometimes when the database
server
interrupts the connection during a query. Seems to be related to the fact that
libmysqlclient's mysql_query() may return success, even if an error occurred,
as
described at:
http://dev.mysql.com/doc/refman/5.5/en/null-mysql-store-result.html
Test script:
---
$resource = mysql_query('SELECT test FROM test');
if ($resource === true) {
throw new Exception('mysql_query() returned true for SELECT');
}
Expected result:
An exception should not be thrown, because the documentation for mysql_query()
at
php.net clearly states that a SELECT query will only ever return false or a
resource.
Actual result:
--
An exception is thrown, because mysql_query() returns true with a SELECT query.
--
Edit this bug report at https://bugs.php.net/bug.php?id=54978edit=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
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 #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
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 #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 #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 #53993 [Opn]: 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
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:
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.
Previous Comments:
[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 #54021 [Opn-Fbk]: incompatiiblity PHP 5.3-mysqli
Edit report at http://bugs.php.net/bug.php?id=54021edit=1
ID: 54021
Updated by: u...@php.net
Reported by:webmaster at racecarstory dot org
Summary:incompatiiblity PHP 5.3-mysqli
-Status: Open
+Status: Feedback
Type: Bug
Package:MySQLi related
Operating System: windows-linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Please, check if any error message becomes visible if setting PHP to
report all errors (http://php.net/manual/en/function.error-reporting.php
,
http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors).
Please, also check the syntax of connect_error/connect_errno
(http://de2.php.net/manual/en/mysqli.connect-errno.php). Your script
could be wrong there.
Previous Comments:
[2011-02-14 21:06:13] webmaster at racecarstory dot org
Description:
i develop webapps in PHP OOP and mysql using mysqli library. this very
simple
query
SELECT * FROM fornitori ORDER BY ragSociale
works ok on localhost on my PC (Windows 7 Pro x64, apache 2.2.17-PHP
5.3.5-MySQL
5.1.55) but on my VPS (centOS 5.5, apache 2.2.16-PHP 5.3.2-MySQL 5.1.48)
doesnt'work! in fact i have crerated a PHP function classes to use
databases and
in some of these i use the following code to check errors:
echo $this-message('Query Error: ' . $mysqli-errno . '\nQuery: ' .
$sql .
'\n\nError: ' . $mysqli-error);
while in localhost tehre isn't any error on my VPS i have teh following
error:
Query Error:
Query: SELECT * FROM fornitori ORDER BY ragSociale
Error:
without any sort of error description. on other web server where i have
a site
(apache 2.2.16-PHP 5.2.13-MySQL 5.1.51) there isn't any error! so i
think: is
this a bug of PHP 5.3 using MySQLi
Test script:
---
function arrayRecords($sql) {
$mysqli = new mysqli($this-host, $this-user, $this-pass,
$this-data);
if ($mysqli) {
$result = $mysqli-query($sql);
if ($result) {
if ($result-num_rows) {
while ($row = $result-fetch_assoc())
$array[] = $row;
} else
$array = array();
} else
echo $this-message('Query Error: ' . $mysqli-errno . '\nQuery:
' . $sql . '\n\nError: ' . $mysqli-error);
} else
echo $this-message('DB Connect Error: ' . $mysqli-connect_errno
. '\nError: ' . $mysqli-connect_error);
//$result-close();
$mysqli-close();
return $array;
}
// with PHP 5.2 works, with PHP 5.3 error!
$rows = $arrayRecords($sql_query);
Expected result:
nothing, it must show a window with the query results
--
Edit this bug report at http://bugs.php.net/bug.php?id=54021edit=1
Bug #54444 [Opn-Bgs]: Multiple Queries on a single conenction
Edit report at http://bugs.php.net/bug.php?id=5edit=1
ID: 5
Updated by: u...@php.net
Reported by:peter dot colclough at toolstation dot com
Summary:Multiple Queries on a single conenction
-Status: Open
+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:
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
Previous Comments:
[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 of what I am trying to achieve if
this helps.
Any help greatly appreciated
OS: 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64
GNU/Linux
PHP Version = 5.3.2-1ubuntu4.5
Test script:
---
-- Code Snippet -
$sqlstock = 'select foo1 from bar1 where foo1 =?';
$sqltime = 'select foo2, foo3 from bar2 where foo4 =?';
$varinp = ;
$abindVars = array(0=$varinp);
$varProd = '';
$conn = dbi-db_conn;
$sprod = '';
$timestart = microtime_float();
// Get a statement
$aRes = array();
$aRes2 = array();
// Init 2 Statements
$stmt = mysqli_stmt_init($conn);
$stmt2 = mysqli_stmt_init($conn);
// Prepare 2 statements
mysqli_stmt_prepare($stmt,$sqlstock);
mysqli_stmt_prepare($stmt2,$sqltime);
// Set the bind variable
$varinp = PXX00019263;
// Bind the statements
mysqli_stmt_bind_param($stmt,'s', $varinp);
mysqli_stmt_bind_param($stmt2,'s', $varinp);
// Execute - Second one fails
mysqli_stmt_execute($stmt);
mysqli_stmt_execute($stmt2);
// Set up field Defs
$aFieldDefs = array();
$aFieldDefs2 = array();
// Get result Metadata
$result = mysqli_stmt_result_metadata($stmt);
$result2 = mysqli_stmt_result_metadata($stmt2);
$nCount = 0;
while($aFieldDefs[$nCount] = mysqli_fetch_field($result)){
echo('Field = '.print_r($aFieldDefs, true).\r\n);
$aRes[$aFieldDefs[$nCount++]-name] = null;
}
$nCount = 0;
while($aFieldDefs2[$nCount] = mysqli_fetch_field($result2)){
echo('Field = '.print_r($aFieldDefs2, true).\r\n);
$aRes2[$aFieldDefs2[$nCount++]-name] = null;
}
// Bind Results
mysqli_stmt_bind_result($stmt, $aRes['foo1']);
mysqli_stmt_bind_result($stmt2, $aRes2['foo2'], $aRes2['foo3'])
// Fetch Results
mysqli_stmt_fetch($stmt);
mysqli_stmt_fetch($stmt2);
echo(print_r($aRes, true).\r\n);
echo(print_r($aRes2, true).\r\n);
--- End Code Snippet --
Expected result:
Array
(
[foo1] = 'PXX00019263'
)
Array
(
[foo2] = 2009-09-15 12:05:02
[foo3] = -00-00 00:00:00
)
Actual result:
--
Array
(
[foo1] =
)
Array
(
[foo2] = 2009-09-15 12:05:02
[foo3] = -00-00 00:00:00
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=5edit=1
Bug #54444 [Bgs]: Multiple Queries on a single conenction
Edit report at http://bugs.php.net/bug.php?id=5edit=1
ID: 5
Updated by: u...@php.net
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:
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();
Previous Comments:
[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 of what I am trying to achieve if
this helps.
Any help greatly appreciated
OS: 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64
GNU/Linux
PHP Version = 5.3.2-1ubuntu4.5
Test script:
---
-- Code Snippet -
$sqlstock = 'select foo1 from bar1 where foo1 =?';
$sqltime = 'select foo2, foo3 from bar2 where foo4 =?';
$varinp = ;
$abindVars = array(0=$varinp);
$varProd = '';
$conn = dbi-db_conn;
$sprod = '';
$timestart = microtime_float();
// Get a statement
$aRes = array();
$aRes2 = array();
// Init 2 Statements
$stmt = mysqli_stmt_init($conn);
$stmt2 = mysqli_stmt_init($conn);
// Prepare 2 statements
mysqli_stmt_prepare($stmt,$sqlstock);
mysqli_stmt_prepare($stmt2,$sqltime);
// Set the bind variable
$varinp = PXX00019263;
// Bind the statements
mysqli_stmt_bind_param($stmt,'s', $varinp);
mysqli_stmt_bind_param($stmt2,'s', $varinp);
// Execute - Second one fails
mysqli_stmt_execute($stmt);
mysqli_stmt_execute($stmt2);
// Set up field Defs
$aFieldDefs = array();
$aFieldDefs2 = array();
// Get result Metadata
$result = mysqli_stmt_result_metadata($stmt);
$result2 = mysqli_stmt_result_metadata($stmt2);
$nCount = 0;
while($aFieldDefs[$nCount] = mysqli_fetch_field($result)){
echo('Field =
Bug-Req #54695 [Opn]: getColumnMeta() throws warning in silent mode
Edit report at http://bugs.php.net/bug.php?id=54695edit=1
ID: 54695
Updated by: u...@php.net
Reported by:david at grudl dot com
Summary:getColumnMeta() throws warning in silent mode
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package:PDO related
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I tend to say that's a valid and important warning. Not every PDO driver
implements this function, see also
http://de2.php.net/manual/en/pdostatement.getcolumnmeta.php .
I read it that you are proposing to implement this function. Thus,
changing from Bug Type Bug to Feature/Change Request..
Previous Comments:
[2011-05-09 16:19:39] david at grudl dot com
Description:
PDO::ERRMODE_SILENT is not respected by PDOStatement::getColumnMeta()
Test script:
---
$pdo = new PDO('sqlite2:demo.db'); // SQLite does not support
getColumnMeta
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT);
$result = $pdo-query('SELECT * FROM users');
$result-getColumnMeta(1);
Expected result:
no warning
Actual result:
--
Warning: PDOStatement::getColumnMeta() [pdostatement.getcolumnmeta]:
SQLSTATE[IM001]: Driver does not support this function: driver doesn't
support meta data
--
Edit this bug report at http://bugs.php.net/bug.php?id=54695edit=1
Bug #54642 [Opn]: Compile w/ MySQLi on OSX fail
Edit report at http://bugs.php.net/bug.php?id=54642edit=1 ID: 54642 Updated by: u...@php.net Reported by:grzegorz129 at gmail dot com Summary:Compile w/ MySQLi on OSX fail Status: Open Type: Bug Package:Compile Failure Operating System: Mac OS X 10.6.8 PHP Version:Irrelevant -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: /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. Previous Comments: [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 #54212 [Opn]: Localhost resolves much more slowly than 127.0.0.1 on mysql_connect()
Edit report at http://bugs.php.net/bug.php?id=54212edit=1
ID: 54212
Updated by: u...@php.net
Reported by:kriscr...@php.net
Summary:Localhost resolves much more slowly than 127.0.0.1
on mysql_connect()
Status: Open
Type: Bug
Package:MySQL related
Operating System: Windows
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
If there is anything, its not MySQL specific. mysqlnd is using PHP
Streams. PHP Streams should be the source. Only other cause I can think
of is MySQL server.
Previous Comments:
[2011-03-10 10:45:51] kriscr...@php.net
Description:
I'm told that a number of people have been reporting this issue. The
reports I'm hearing state that people are finding it to be about 3-4
times slower when done by hostname.
My guess would be this is another IPv6-related issue. It's also worth
noting that I have not yet been able to independently verify these
numbers, though I am working on doing so and will post the data if/when
I have it.
It was requested that I post this bug so that we have a record of it.
If you've experienced any hostname vs. IP performance issues (good or
bad), please post a comment here so we have the reports in one central
place. Thanks!
Test script:
---
?php
if ( !isset( $_GET[host] ) )
{
die( You must specify ?host= in the URL string. Example:
mysql_connect_test.php?host=localhost );
}
$start = microtime( TRUE );
$link = mysql_connect( $_GET[host], root, (your-password-here) )
or die( Function mysql_connect() failed. );
$end = microtime( TRUE );
$duration = $end - $start;
print bExecution Time:/bnbsp; $duration secbr /\r\n;
--
Edit this bug report at http://bugs.php.net/bug.php?id=54212edit=1
Bug #53551 [Asn-Csd]: PDOStatement execute segfaults for pdo_mysql driver
Edit report at http://bugs.php.net/bug.php?id=53551edit=1
ID: 53551
Updated by: u...@php.net
Reported by:eddawley at gmail dot com
Summary:PDOStatement execute segfaults for pdo_mysql driver
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Centos 5
PHP Version:5.3.4
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
See SVN note
Previous Comments:
[2011-01-14 15:57:59] johan...@php.net
Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307478
Log: - Fix #53551 (PDOStatement execute segfaults for pdo_mysql driver)
[2011-01-06 12:03:48] u...@php.net
That fix should do it, however, I'd like to wait until Johannes returns
from vacation and reviews it. PDO is a bit of a beast. With the fix the
code should neither crash nor leak, nor behave differently from
PDO_SQlite. Anyway, the result is still pretty, well, PDOish weird:
error codes not cleaned up properly upon rebinding. Not my cup of
coffee...
Index: ext/pdo_mysql/mysql_statement.c
===
--- ext/pdo_mysql/mysql_statement.c (Revision 307155)
+++ ext/pdo_mysql/mysql_statement.c (Arbeitskopie)
@@ -141,10 +141,12 @@
/* (re)bind the parameters */
if (mysql_stmt_bind_param(S-stmt, S-params) ||
mysql_stmt_execute(S-stmt)) {
+ /*
if (S-params) {
efree(S-params);
S-params = 0;
}
+ */
pdo_mysql_error_stmt(stmt);
if (mysql_stmt_errno(S-stmt) == 2057) {
/* CR_NEW_STMT_METADATA makes the statement
unusable */
[2010-12-17 20:58:27] eddawley at gmail dot com
Sorry, I didn't realize I was being unclear. The segfault is occurring
with PDO
using libmysql.
Here are my relevant configure options:
'--with-mysql=mysqlnd' '--with-mysqli' '--with-pdo-mysql'
[2010-12-17 20:44:00] ka...@php.net
MySQLnd is not a driver, its a library backend. MySQL, MySQLi and
PDO_MySQL can all be powered by either libmysql or mysqlnd.
So what you are saying is that you built pdo_mysql against libmysql
which segfaults?
[2010-12-17 19:38:02] eddawley at gmail dot com
I would like to add that this happens for other mysql-level errors. For
example, the following will also cause a segfault when reused:
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or
update a
child
row: a foreign key constraint fails ...
SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for
column...
And again, this was noticed with the pdo_mysql driver. NOT the mysqlnd
native
driver.
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=53551
--
Edit this bug report at http://bugs.php.net/bug.php?id=53551edit=1
Bug #53287 [Fbk]: PDO 5 Byte write to a broken pipe when forked
Edit report at http://bugs.php.net/bug.php?id=53287edit=1
ID: 53287
Updated by: u...@php.net
Reported by:bryan dot tong at gigenet dot com
Summary:PDO 5 Byte write to a broken pipe when forked
Status: Feedback
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86-64
PHP Version:5.3SVN-2010-11-10 (snap)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
This does not smell like an error rather more like mysqlnd being more
verbose. No bug, a feature, I'd say.
Previous Comments:
[2010-12-05 21:23:46] seza at paradoxal dot org
I have the same error message with php.5.3.3 (send of 5 bytes failed
with errno=32 Broken pipe) but in a
different context more simply to reproduce :
I have a simple website (no fork or stuff like that). It make persistent
connection with pdo to mysql
(mysqlnd). The errors are raised when the mysql is server is restarted.
When mysql server is off error message are mysql server is gone away. No
problem with that but once the
mysql server is restarted and during 15 minutes I have sometimes this
error message (send of 5 bytes
failed with errno=32 Broken pipe).
Certainly a reuse of a cached connection to mysql before it was
restarted.
PS : I use mysql_sock connection
(mysql:unix_socket=/var/run/mysqld/mysqld.sock)
[2010-11-26 13:19:45] johan...@php.net
The description mentions forking, the sample code not. Please provide a
complete script showing the issue.
[2010-11-10 03:21:00] bryan dot tong at gigenet dot com
Description:
When switching from PHP 5.1.6 to PHP 5.3.3 the following notice has
begun to show up in our scripts.
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe
We are running a daemon and the forked children throw this error on the
PDO construct that is used to refresh the class.
The error changes depending on whether a persistent connection is set or
not.
When persistent is on the above error is produced. Without persistent
connection applied the error is thrown when the class is destructed.
Example: $pdo = null;
send of 5 bytes failed with errno=32 Broken pipe
We have confirmed this to be apparent in PHP 5.3.3 and the trunk build.
I was unable to test on 5.2, but I was able to confirm this bug does not
occur on 5.1.6
I have tried wrapping ob functions around the calls in case the broken
pipe happened to be stdout but I think it is the mysql socket that is in
question. On that same note, switching mysql to connect via tcp did not
help.
From searching I found a site that threw this error but no discussions
of it.
Let me know any additional information that is needed.
Test script:
---
// without persistance
public static function shutdown(){
$base = Base::getBase();
$base-db = null;
self::$base = false;
}
// with persistance
$this-pdo = new PDO(
$dsn,
$user,
$pass,
array(
PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_PERSISTENT= true
)
);
Expected result:
The PDO class should startup quietly when persistent connections are
enabled and destruct quietly when persistent connections are disabled.
Actual result:
--
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe
with persistent connections.
Base::shutdown(): send of 5 bytes failed with errno=32 Broken pipe
without persistent connections.
I believe this problem is only related to forked processes. I have
confirmed the standard page serving to not throw this.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53287edit=1
Bug #53795 [Opn]: Connect Error from MySqli (mysqlnd) when using SSL
Edit report at http://bugs.php.net/bug.php?id=53795edit=1
ID: 53795
Updated by: u...@php.net
Reported by:dave dot kelly at dawkco dot com
Summary:Connect Error from MySqli (mysqlnd) when using SSL
Status: Open
Type: Bug
Package:MySQLi related
Operating System: Windows
PHP Version:5.3.5
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
mysqlnd does not read default files, AFAIK. I think Andrey wants to
deprecate that, Andrey?
Previous Comments:
[2011-01-20 01:59:47] dave dot kelly at dawkco dot com
Description:
- Using PHP 5.3.5 Windows binaries (Zip package).
- extension = php_mysqli.dll is enabled in php.ini.
- trying to use mysqli::real_connect, passing MYSQLI_CLIENT_SSL in the
flags parameter.
It returns the following error:
Warning: mysqli::real_connect() [mysqli.real-connect.html]:
(28000/1045): Access denied for user 'user'@'host' (using password: YES)
in C:\Apache22\htdocs\test.php on line 25
Connect Error (1045)
If I switch to PHP 5.2.17 Windows binaries (Zip package), using the
exact same settings and script, I get the following (excerpts):
Success... host via TCP/IP
...
Ssl_cipher DHE-RSA-AES256-SHA
...
Ssl_version TLSv1
I believe the main difference (relevant to this problem) between PHP
5.2.17 and PHP 5.3.5 is that 5.2.17 uses libmysql.dll and 5.3.5 uses
built-in mysqlnd (native driver). So, it appears that libmysql.dll
works with SSL, while built-in mysqlnd (native driver) cannot use SSL.
The Windows binaries build has no way to disable/enable mysqlnd and/or
libmysql. If mysqlnd is not going to work with SSL, there should at
least be another option that can be configured at runtime with the
options file.
Test script:
---
?php $mysqli = new mysqli();
$mysqli-init();
if (!$mysqli-options(MYSQLI_READ_DEFAULT_FILE,
'C:/Program Files/MySQL/my.ini')) {
die('Setting MYSQLI_READ_DEFAULT_FILE failed');
}
if (!$mysqli-options(MYSQLI_READ_DEFAULT_GROUP, 'mysql')) {
die('Setting MYSQLI_READ_DEFAULT_GROUP failed');
}
if (!$mysqli-real_connect('host', 'user', 'pass',
'mydb', 3306, NULL, MYSQLI_CLIENT_SSL)) {
echo 'Connect Error (' . mysqli_connect_errno() . ')' . br /\n;
}
else {
echo 'Success... ' . $mysqli-host_info . br /\n;
$sql = show status like '%ssl%';
$result = $mysqli-query($sql);
while ($row = $result-fetch_array()) {
echo $row[0] . ' ' . $row[1] . br /\n;
}
if ($result) { $result-close(); }
}
$mysqli-close(); ?
Expected result:
Expect a new SSL connection and a result set from the query indicating
that the connection is indeed via SSL/TLS.
Actual result:
--
Warning: (28000/1045): Access denied ... Connect Error (1045).
--
Edit this bug report at http://bugs.php.net/bug.php?id=53795edit=1
Req #41402 [Asn-Wfx]: no safe way to retrieve warnings
Edit report at http://bugs.php.net/bug.php?id=41402edit=1
ID: 41402
Updated by: u...@php.net
Reported by:corinl at gmx dot de
Summary:no safe way to retrieve warnings
-Status: Assigned
+Status: Wont fix
Type: Feature/Change Request
Package:MySQLi related
Operating System: debian 686
PHP Version:5.2.2
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Can be handled in user space.
Previous Comments:
[2011-01-06 14:46:35] u...@php.net
Not needed, there is
http://de3.php.net/manual/en/mysqli.warning-count.php to check if
warnings exist and if they do, you can fetch them in user space and
preserve all mysqli properties you are interested in.
[2007-05-15 16:19:12] corinl at gmx dot de
Description:
using $m-query('SHOW WARNINGS') changes $m-affected_rows, so it cannot
be used when extending the class. also, affected_rows is write protected
so it cannot be saved and restored after fetching the warnings.
$m-get_warnings() does not seem to work yet.
Reproduce code:
---
see above
Expected result:
please make $m-query('SHOW WARNINGS') not to change change
$m-affected_rows. if this is not desired, please make get_warnings()
functional.
--
Edit this bug report at http://bugs.php.net/bug.php?id=41402edit=1
Req #28075 [Asn-Wfx]: mysql ssl connection
Edit report at http://bugs.php.net/bug.php?id=28075edit=1
ID: 28075
Updated by: u...@php.net
Reported by:petre dot rodan at avira dot com
Summary:mysql ssl connection
-Status: Assigned
+Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: *
PHP Version:*
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
See previous comment: use mysqli.
Previous Comments:
[2011-01-06 17:14:31] u...@php.net
... don't think we should add functionality to ext/mysql. People should
move forward and use mysqli. Also, there's a work around documented in
the bug.
[2007-07-13 10:45:45] Bruno dot Harbulot at manchester dot ac dot uk
I have just tried this suggestion (using mysql_options to read the
[client] section of the global mysql configuration file). It works.
However, it doesn't seem like a good idea to use a global client
configuration for all the MySQL connections from PHP. There can be
scenarios where different certificates or CAs might be required.
Perhaps it would be better to have a binding of mysql_ssl_set (part of
the MySQL API) to the PHP MySQL extension. It seems that MySQLi supports
it.
See:
http://dev.mysql.com/doc/refman/5.0/en/mysql-ssl-set.html
http://www.php.net/manual/en/function.mysqli-ssl-set.php
Regards,
Bruno.
[2004-04-20 15:54:40] der...@php.net
Assigning to georg, the maintainer of this extension.
[2004-04-20 12:34:11] petre dot rodan at avira dot com
Description:
I was tring to use SSL-enabled mysql connections using php and mod_php.
The problem was that the libmysql library inside {,mod_}php detects that
SSL is needed, but it doesn't know the location of the client
certificate.
by simply inserting the following line
mysql_options(mysql-conn,MYSQL_READ_DEFAULT_GROUP,client);
before mysql_real_connect(..) in ext/mysql/php_mysql.c, the my.cnf file
is read and all SSL-related configurations are imported from there.
If my problem can be solved in another way, please drop me a line :).
Successfuly tested with php-4.3.4-r4, mod_php-4.3.4-r4,
mod_php-4.3.6-rc2, php-5.0_beta1-r1.
see
http://bugs.gentoo.org/show_bug.cgi?id=46340#c3
for scenario details
the patch can be downloaded here:
http://bugs.gentoo.org/attachment.cgi?id=28436action=view
--
Edit this bug report at http://bugs.php.net/bug.php?id=28075edit=1
Req #19974 [Wfx]: force close persistent SQL connections
Edit report at http://bugs.php.net/bug.php?id=19974edit=1
ID: 19974
Updated by: u...@php.net
Reported by:artem at osp dot ru
Summary:force close persistent SQL connections
Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: Linux
PHP Version:4.2.3
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
ext/mysql does not export mysql_change_user(). It cannot be called from
PHP. However, I agree with Won't fix.
Previous Comments:
[2011-01-07 15:36:18] and...@php.net
Please use mysql_change_user() to reset the connection
[2011-01-06 17:20:28] u...@php.net
... don't think we should do anything on it. That magic new function is
mysql_change_user, its called by default with mysqli to clean up
connection, its exported in the mysqli API. People should just move
forward to mysqli.
[2002-10-21 02:53:14] artem at osp dot ru
You can call it function
'mysql_reset_connection' or 'mysql_pclose', as you like.
Of course, the target of this function is close those disadvantages,
which you list.
[2002-10-18 08:46:40] ge...@php.net
When you have a pclose, there is no need for pconnect, you
can also use mysql_connect.
Currently the problem is, that persistent connections in
MySQL have some disadvantages/bugs/problems:
- no unset for user variables
- session variables are not restored to global variables
- no unlock for tables
- unselect previous selected database
- temporary tables are not deleted
- ROLLBACK of not commited transactions
- SQL_FOUND_ROWS returns a valid result
currently MySQL AB works on a new api-function
mysql_reset_connection to fix all these things, so we have
to wait. Currently there is not enough functionality to
fix/handle this inside the mysql extension.
[2002-10-18 07:13:16] artem at osp dot ru
From time to time I need close my SQL connections becose using Lock,
temporary tables, etc. But such code executed rare.
Can you add new function?
like:
bool mysql_pclose ([bool on_script_exit_or_now=FALSE,[resource
link_identifier]])
This function will allow easy using locks and temporary tables and do
not loose efficiency.
using this function can be such:
--
mysql_pconnent(...);
...
if(rare_case) {
mysql_pclose(TRUE); # close connect at exit
mysql_query(create temporary table );
...
}
-
or such:
--
mysql_pconnent(...);
...
if(rare_case) {
mysql_query(create temporary table );
...
mysql_pclose(); # close connect now
}
-
--
Edit this bug report at http://bugs.php.net/bug.php?id=19974edit=1
Req #53657 [Wfx]: Make at least PDOStatement::bindValue and PDOStatement::bindParam() chainable!
Edit report at http://bugs.php.net/bug.php?id=53657edit=1
ID: 53657
Updated by: u...@php.net
Reported by:schindhelm at gmail dot com
Summary:Make at least PDOStatement::bindValue and
PDOStatement::bindParam() chainable!
Status: Wont fix
Type: Feature/Change Request
Package:*Database Functions
Operating System: any
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Use: execute(array(values))
Previous Comments:
[2011-01-06 03:01:38] ahar...@php.net
The bind methods already have defined return values. I don't see any
benefit to breaking backward compatibility for such a minor potential
gain.
[2011-01-05 19:33:25] schindhelm at gmail dot com
Description:
---
From manual page: http://www.php.net/pdostatement.bindvalue
---
The PDOStatement::bindValue and PDOStatement::bindParam methods should
be chainable. Look at my test script below for an example.
Test script:
---
// create a new PDO
$dbh = new PDO($dsn, $user, $pass);
// the example SQL statement
$sql = INSERT INTO db.table (id, firstName, lastName) VALUES(NULL,
:firstName, :lastName);
$statement = $dbh-prepare($sql);
// current behaviour
$statement-bindValue(':firstName', 'Foo');
$statement-bindValue(':lastName', 'Bar');
// and so on...
$statement-execute();
// what I wish for and what saves a lot of copy paste, but especially
time
$statement-bindValue(':firstName', 'Foo')
-bindValue(':lastName', 'Bar');
-execute();
--
Edit this bug report at http://bugs.php.net/bug.php?id=53657edit=1
Bug #53551 [Asn]: PDOStatement execute segfaults for pdo_mysql driver
Edit report at http://bugs.php.net/bug.php?id=53551edit=1
ID: 53551
Updated by: u...@php.net
Reported by:eddawley at gmail dot com
Summary:PDOStatement execute segfaults for pdo_mysql driver
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Centos 5
PHP Version:5.3.4
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
That fix should do it, however, I'd like to wait until Johannes returns
from vacation and reviews it. PDO is a bit of a beast. With the fix the
code should neither crash nor leak, nor behave differently from
PDO_SQlite. Anyway, the result is still pretty, well, PDOish weird:
error codes not cleaned up properly upon rebinding. Not my cup of
coffee...
Index: ext/pdo_mysql/mysql_statement.c
===
--- ext/pdo_mysql/mysql_statement.c (Revision 307155)
+++ ext/pdo_mysql/mysql_statement.c (Arbeitskopie)
@@ -141,10 +141,12 @@
/* (re)bind the parameters */
if (mysql_stmt_bind_param(S-stmt, S-params) ||
mysql_stmt_execute(S-stmt)) {
+ /*
if (S-params) {
efree(S-params);
S-params = 0;
}
+ */
pdo_mysql_error_stmt(stmt);
if (mysql_stmt_errno(S-stmt) == 2057) {
/* CR_NEW_STMT_METADATA makes the statement
unusable */
Previous Comments:
[2010-12-17 20:58:27] eddawley at gmail dot com
Sorry, I didn't realize I was being unclear. The segfault is occurring
with PDO
using libmysql.
Here are my relevant configure options:
'--with-mysql=mysqlnd' '--with-mysqli' '--with-pdo-mysql'
[2010-12-17 20:44:00] ka...@php.net
MySQLnd is not a driver, its a library backend. MySQL, MySQLi and
PDO_MySQL can all be powered by either libmysql or mysqlnd.
So what you are saying is that you built pdo_mysql against libmysql
which segfaults?
[2010-12-17 19:38:02] eddawley at gmail dot com
I would like to add that this happens for other mysql-level errors. For
example, the following will also cause a segfault when reused:
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or
update a
child
row: a foreign key constraint fails ...
SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for
column...
And again, this was noticed with the pdo_mysql driver. NOT the mysqlnd
native
driver.
[2010-12-16 22:58:35] ka...@php.net
I cannot reproduce with php-trunk using pdo_mysql linked to mysqlnd on
Windows:
C:\phpphp test.php
1
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
2
array(3) {
[0]=
string(5) 0
[1]=
NULL
[2]=
NULL
}
done
C:\phpphp -v
PHP 5.3.99-dev (cli) (built: Dec 11 2010 12:14:13)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
[2010-12-15 22:31:18] eddawley at gmail dot com
Description:
A segfault will occur when a PDOStatement is reused after failing due to
a NOT
NULL integrity constraint. This occurred when using the pdo_mysql
driver as
opposed to the mysqlnd driver.
Also to avoid confusion, I was only able to test this on PHP 5.3.2. I
could find
nothing in the changelogs that would imply this bug has been fixed. I
unfortunately did not have the time to free up hardware or vms for an
upgrade.
Test script:
---
$dbh = new PDO('mysql:host=127.0.0.1;dbname=foo', 'user', 'pass');
$dbh-setAttribute(PDO::ATTR_EMULATE_PREPARES, 0);
$createSql = CREATE TABLE `foo` (
`count` bigint(20) unsigned NOT NULL DEFAULT '0'
);
$dbh-exec('drop table if exists foo');
$dbh-exec($createSql);
$dbh-exec(insert into foo set `count` = 1 );
$sql = 'UPDATE foo
Bug #53483 [Opn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483edit=1
ID: 53483
Updated by: u...@php.net
Reported by:squarious at gmail dot com
Summary:using mysqli_stmt::send_long_data() makes execute()
fail
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Please always add complete test. Never link external sites.
?php
// Reproduce bug that with send_long_data, execute() fails
// Agjust your settings before execute
$conn = new mysqli(
'localhost',// Server
'root', // Username
'root', // Password
'test' // Schema
);
if (!$conn-query('CREATE TABLE IF NOT EXISTS `test_bug_blob` (`id`
integer auto_increment, `data` BLOB, PRIMARY KEY(`id`));'))
die(Error creating table.\n);
if (!($result = $conn-query('SELECT @@max_allowed_packet')))
die(Error reading max allowed packet size.\n);
$max_allowed_packet = $result-fetch_array();
$max_allowed_packet = $max_allowed_packet[0];
if (!($stmt = $conn-prepare('INSERT INTO `test_bug_blob` (`data`)
VALUES (?)')))
die(Cannot prepare statement for INSERT. {$conn-error}\n);
// Sent blob smaller than max allowed_packet
$data = str_repeat('0123456789', $max_allowed_packet/20);
if (!$stmt-bind_param('s', $data))
die(Error binding parameters. {$stmt-error}\n);
if (!$stmt-execute())
die(Error executing prepared statement. {$stmt-error}\n);
echo OK: Executed prepared statement with blob less than
max_allowed_packet.\n;
// Sent blob bigger than max allowed_packet
$big_data = str_repeat('0123456789', $max_allowed_packet/9);
$null = null;
if (!$stmt-bind_param('b', $null))
die(Error binding parameters. {$stmt-error}\n);
foreach(str_split($big_data, $max_allowed_packet) as $packet )
if (!$stmt-send_long_data(0, $packet))
die(Error sending long packet. {$stmt-error}\n);
if (!$stmt-execute())
die(Error executing prepared statement. {$stmt-error}\n);
echo OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.\n;
Previous Comments:
[2010-12-20 17:56:32] jbreton at kronostechnologies dot com
I upgraded mysql to 5.1.54 using debian experimental packages and the
problem is
gone.
Hopefully it won't break my ubuntu setup, which was a brand new 10.10
using
official packages.
[2010-12-20 17:14:09] jbreton at kronostechnologes dot com
You haven't tried mysql5.1.49 which was specified in squarious'
description.
I just tried with php 5.3.4 stable and mysql5.1.49 without success.
[2010-12-20 17:14:07] jbreton at kronostechnologes dot com
You haven't tried mysql5.1.49 which was specified in squarious'
description.
I just tried with php 5.3.4 stable and mysql5.1.49 without success.
[2010-12-20 16:51:45] and...@php.net
I can't reproduce the problem :(
[2010-12-20 16:50:58] and...@php.net
libmysql + MySQL 5.1.55
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
mysqlnd + MySQL 5.1.55
and...@poohie:~/PHP_5_3$ ./php a.php
OK: Executed prepared statement with blob less than max_allowed_packet.
OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.
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=53483
--
Edit this bug report at http://bugs.php.net/bug.php?id=53483edit=1
Bug #53483 [Opn-Asn]: using mysqli_stmt::send_long_data() makes execute() fail
Edit report at http://bugs.php.net/bug.php?id=53483edit=1
ID: 53483
Updated by: u...@php.net
Reported by:squarious at gmail dot com
Summary:using mysqli_stmt::send_long_data() makes execute()
fail
-Status: Open
+Status: Assigned
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.3.3
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Andrey,
smells like a server bug fixed in the latest 5.0, 5.1. 5.5 series. Below
is mysqlnd @ 64bit @ MySQL 5.1.45.
Ulf
nixn...@linux-fuxh:~/php/php-src/branches/PHP_5_3_cta sapi/cli/php
foo.php
array(1) {
[client_info]=
string(48) mysqlnd 5.0.7-dev - 091210 - $Revision: 306939 $
}
array(1) {
[server_info]=
string(12) 5.1.45-debug
}
OK: Executed prepared statement with blob less than max_allowed_packet.
Error executing prepared statement. Got a packet bigger than
'max_allowed_packet' bytes
Previous Comments:
[2011-01-06 14:20:01] u...@php.net
Please always add complete test. Never link external sites.
?php
// Reproduce bug that with send_long_data, execute() fails
// Agjust your settings before execute
$conn = new mysqli(
'localhost',// Server
'root', // Username
'root', // Password
'test' // Schema
);
if (!$conn-query('CREATE TABLE IF NOT EXISTS `test_bug_blob` (`id`
integer auto_increment, `data` BLOB, PRIMARY KEY(`id`));'))
die(Error creating table.\n);
if (!($result = $conn-query('SELECT @@max_allowed_packet')))
die(Error reading max allowed packet size.\n);
$max_allowed_packet = $result-fetch_array();
$max_allowed_packet = $max_allowed_packet[0];
if (!($stmt = $conn-prepare('INSERT INTO `test_bug_blob` (`data`)
VALUES (?)')))
die(Cannot prepare statement for INSERT. {$conn-error}\n);
// Sent blob smaller than max allowed_packet
$data = str_repeat('0123456789', $max_allowed_packet/20);
if (!$stmt-bind_param('s', $data))
die(Error binding parameters. {$stmt-error}\n);
if (!$stmt-execute())
die(Error executing prepared statement. {$stmt-error}\n);
echo OK: Executed prepared statement with blob less than
max_allowed_packet.\n;
// Sent blob bigger than max allowed_packet
$big_data = str_repeat('0123456789', $max_allowed_packet/9);
$null = null;
if (!$stmt-bind_param('b', $null))
die(Error binding parameters. {$stmt-error}\n);
foreach(str_split($big_data, $max_allowed_packet) as $packet )
if (!$stmt-send_long_data(0, $packet))
die(Error sending long packet. {$stmt-error}\n);
if (!$stmt-execute())
die(Error executing prepared statement. {$stmt-error}\n);
echo OK: Executed prepared statement with blob bigger than
max_allowed_packet, sent at chunks.\n;
[2010-12-20 17:56:32] jbreton at kronostechnologies dot com
I upgraded mysql to 5.1.54 using debian experimental packages and the
problem is
gone.
Hopefully it won't break my ubuntu setup, which was a brand new 10.10
using
official packages.
[2010-12-20 17:14:09] jbreton at kronostechnologes dot com
You haven't tried mysql5.1.49 which was specified in squarious'
description.
I just tried with php 5.3.4 stable and mysql5.1.49 without success.
[2010-12-20 17:14:07] jbreton at kronostechnologes dot com
You haven't tried mysql5.1.49 which was specified in squarious'
description.
I just tried with php 5.3.4 stable and mysql5.1.49 without success.
[2010-12-20 16:51:45] and...@php.net
I can't reproduce the problem :(
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=53483
--
Edit this bug report at http://bugs.php.net/bug.php?id=53483edit=1
Req #49280 [Opn-Wfx]: ext/mysqlnd: Not possible to detect mysqlnd in php
Edit report at http://bugs.php.net/bug.php?id=49280edit=1 ID: 49280 Updated by: u...@php.net Reported by:ar at ez dot no Summary:ext/mysqlnd: Not possible to detect mysqlnd in php -Status: Open +Status: Wont fix Type: Feature/Change Request Package:MySQLi related Operating System: * PHP Version:5.3.0 -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: Original issue was bogus (persistent connections). Too few relevant differences between mysqlnd and libmysql otherwise and none that you can't easily detect by e.g. using mysqli-client_info. No need for an extra constant. Previous Comments: [2009-08-17 17:28:58] ar at ez dot no And you really should be checking if mysql*.allow_persistent is on or off anyway We don't need hide php warnings, so if php trows a understandable warning in such a case, then that would be sufficient. So, for my use case this is not valid anymore then, Thanks;) But as long as mysqlnd behaves differently then the old mysql client, I would vote for such a constant anyway. Or you can close with reference to the first comment(2:21) on how to detect mysqlnd if you absolutely need to know about it in code. [2009-08-17 17:18:45] j...@php.net p: is allowed always since PHP 5.3.0. You only get a warning when someone has disabled persistent connections with mysqli.allow_persistent ini option. You don't need to know whether it's mysqlnd or libmysql that is used. And you really should be checking if mysql*.allow_persistent is on or off anyway. :) [2009-08-17 14:53:12] ar at ez dot no Hi jani! I'm not trying to workaround anything, its just that Persistent Connections are only supported on mysqli when mysqlnd is used. So it doesn't help to detect php version using PHP_VERSION, as the end user might have mysqlnd disabled / not compiled in. It is possible to detect it by by using function_exists. But since you guys might add those extra mysqlnd functions to the other mysql driver as well, that is not reliable not to mention clean. see: http://no.php.net/mysqli.mysqlnd For what I'm trying to do: eZ Publish like other php projects abstracts things, one of those is Persistent connection, witch is abstracted into a ini setting (changeable in admin gui). So I need to prepend p: IF user has mysqlnd, or trow a warning about unsupported setting. [2009-08-17 14:30:15] j...@php.net So you want to circumvent a bug by adding a constant instead of fixing the actual bug? Can you please explain WHAT does not work like it should when you have enabled mysqlnd..? [2009-08-17 14:21:35] ar at ez dot no Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. 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=49280 -- Edit this bug report at http://bugs.php.net/bug.php?id=49280edit=1
Req #41402 [Asn]: no safe way to retrieve warnings
Edit report at http://bugs.php.net/bug.php?id=41402edit=1
ID: 41402
Updated by: u...@php.net
Reported by:corinl at gmx dot de
Summary:no safe way to retrieve warnings
Status: Assigned
Type: Feature/Change Request
Package:MySQLi related
Operating System: debian 686
PHP Version:5.2.2
-Assigned To:georg
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Not needed, there is
http://de3.php.net/manual/en/mysqli.warning-count.php to check if
warnings exist and if they do, you can fetch them in user space and
preserve all mysqli properties you are interested in.
Previous Comments:
[2007-05-15 16:19:12] corinl at gmx dot de
Description:
using $m-query('SHOW WARNINGS') changes $m-affected_rows, so it cannot
be used when extending the class. also, affected_rows is write protected
so it cannot be saved and restored after fetching the warnings.
$m-get_warnings() does not seem to work yet.
Reproduce code:
---
see above
Expected result:
please make $m-query('SHOW WARNINGS') not to change change
$m-affected_rows. if this is not desired, please make get_warnings()
functional.
--
Edit this bug report at http://bugs.php.net/bug.php?id=41402edit=1
Req #39847 [Opn]: mysqli_fetch_[field|fields|field_direct] need to return db
Edit report at http://bugs.php.net/bug.php?id=39847edit=1 ID: 39847 Updated by: u...@php.net Reported by:marzillo at emdeon dot com Summary:mysqli_fetch_[field|fields|field_direct] need to return db Status: Open Type: Feature/Change Request Package:MySQLi related Operating System: * PHP Version:5.2.0 -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: Andrey? Sounds like a valid request... let's do Previous Comments: [2006-12-15 19:51:36] marzillo at emdeon dot com Description: The mysqli functions fetch_field, fetch_fields and fetch_field_direct do not return the db name when the C API allows it. For the past several versions I have been adding the following code to mysqli_api.c to include this field. Could this be included in future releases? mysqli_fetch_field function add_property_string(return_value, db,(field-db ? field-db : ), 1); mysqli_fetch_fields function add_property_string(obj, db,(field-db ? field-db : ), 1); mysqli_fetch_field_direct add_property_string(return_value, db,(field-db ? field-db : ), 1); -- Edit this bug report at http://bugs.php.net/bug.php?id=39847edit=1
Req #39235 [Opn]: Permit parameters in execute()
Edit report at http://bugs.php.net/bug.php?id=39235edit=1
ID: 39235
Updated by: u...@php.net
Reported by:mark dot 2391 at blueyonder dot co dot uk
Summary:Permit parameters in execute()
Status: Open
Type: Feature/Change Request
Package:MySQLi related
Operating System: Debian GNU/Linux
PHP Version:5.1.6
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
What shall happen to bound parameters after the first execution (error
or not) of the statement? Shall mysqli try to use the same parameters
for a new call to execute even if no values are passed to the execute
method?
stmt-execute(bound_values) - OK
stmt-execute() - reuse bound_values?
stmt-execute(bound_values) - error
stmt-execute() - reuse bound_values?
Or:
stmt-execute(bound_values) - OK
stmt-execute() - error: no values given
What shall happen if parameters have been bound but execute gets called
with new parameters:
stmt-bind(value) - use value
stmt-execute(another_value) - use another_value?
Or:
stmt-bind(value) - use value
stmt-execute(another_value) - error: must not mix syntax
Ulf
Previous Comments:
[2006-10-23 13:05:14] mark dot 2391 at blueyonder dot co dot uk
Description:
I want to convert to MySqli from PDO's MySql driver as I'm hitting a
known bug in PDO that isn't getting fixed and I figure MySqli would be
faster anyway.
However, MySqli appears to be restrictive when compared to PDO in its
insistence that I use bind_params(). PDO allows the alternative to pass
Mysql parameters as an array to its execute() method.
My Mysql parameters are passed to me as an array in my code.
I do not know a way in PHP of passing an array of these parameters to
MySQLi while it insists on using bind_params which in turn insists on a
fixed list of named variables.
As I say, PDO copes with this as it's execute() method offers the
alternative choice while params to MySqli's execute() are marked as
void, and so it seems to me impossible to implement my Data Access
Service layer (which manages DB access on similar lines to the PHP SDO
extension) with Mysqli at the moment unless I completely lose the
advantage of prepared statements.
The code below hopefully illustrates the kind of usage I need (and as I
say, PDO allows). Perhaps there is a workaround I have not thought of.
Thanks in advance for any comments/tips,
Mark
Reproduce code:
---
?php
// I propose this change to the mysqli_stmt_execute() syntax allowing me
to do something like the following:
// bool mysqli_stmt_execute ( mysqli_stmt stmt [string types, array
input_parameters] )
$dbh = new mysqli(localhost, my_user, my_password, world);
$sql = 'INSERT INTO TableA VALUES (?, ?)';
$mysqlParamsStringTypes = 'is';
$mysqlParams = array('1', 'a');
$myDasStmt = new MyDasStmt($dbh, $sql, $mysqlParamsStringTypes);
$myDasStmt-execute($mysqlParams);
class MyDasStmt
{
protected $mysqlParamsStringTypes;
protected $stmt;
public function __construct($dbh, $sql, $mysqlParamsStringTypes)
{
$this-stmt = $dbh-stmt_init();
$this-stmt-prepare($sql);
}
public function execute(array $mysqlParams)
{
$this-stmt-execute($this-mysqlParamsStringTypes,
$mysqlParams);
// ...
}
}
?
Expected result:
N/A
Actual result:
--
N/A
--
Edit this bug report at http://bugs.php.net/bug.php?id=39235edit=1
Req #38150 [Opn-Asn]: Please add row tell and seek for mysqli
Edit report at http://bugs.php.net/bug.php?id=38150edit=1
ID: 38150
Updated by: u...@php.net
Reported by:php at adaniels dot nl
Summary:Please add row tell and seek for mysqli
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:MySQLi related
Operating System: Any
PHP Version:5.1.4
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
That's for buffered results only. I don't see a big win considering the
iterator support added rather recently (but not properly documented).
Johannes, what's your take?
Previous Comments:
[2006-07-19 19:13:24] php at adaniels dot nl
I mean:
function get_all_rows(mysqli_result $result)
{
$ptr = $result-row_tell();
$rows = array();
$result-data_seek(0);
while ($row = $result-fetch_row()) $rows[] = $row;
$result-row_seek($ptr);
return $rows;
}
[2006-07-19 19:06:42] php at adaniels dot nl
Description:
The mysql API functions mysql_row_tell and mysql_row_seek are not ported
to the mysqli libary.
I believe this is a shame, because currently it isn't possible to create
a function which uses a mysql_result but does not influence the code
outside of the function.
I do not see the fact that, mysqli_row_seek would return a resource and
not an actual rownumber, as a problem.
P.S. If it is generaly agreed that this is a usefull feature, but there
are no volenteers to add the function, I volenteer myself.
Reproduce code:
---
I would like to do the following:
function get_all_rows(mysqli_result $result)
{
$ptr = $result-row_tell();
$rows = array();
while ($row = $result-fetch_row()) $rows[] = $row;
$result-row_seek($ptr);
return $rows;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=38150edit=1
Req #38144 [Opn-Asn]: mysqli_real_connect
Edit report at http://bugs.php.net/bug.php?id=38144edit=1 ID: 38144 Updated by: u...@php.net Reported by:traufei...@php.net Summary:mysqli_real_connect -Status: Open +Status: Assigned Type: Feature/Change Request Package:MySQLi related Operating System: CentOS 4 PHP Version:5CVS-2006-07-19 (CVS) -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: I'm no fan of it. mysqlnd does not support client config files anyway. Previous Comments: [2006-07-19 15:30:27] traufei...@php.net Description: Hi, the mysql client libs allow using a user specified my.cnf. Such a configfile can already be set with mysqli_options and MYSQLI_READ_DEFAULT_FILE. The configfile can contain a password for connections. Such a password is only read, if the password-parameter to the mysql_real_connect c-function is NULL. Passing NULL as password to mysqli_real_connect gets converted to an empty string during zend_parse_method_parameters, so the configfile is not used for a password. At http://www.phpschlampe.de/mysqli.patch is a tiny patch to allow NULL-values for the password. This patch is against 5.2. After patching the following works: ?php $mysqli = mysqli_init(); mysqli_options($mysqli,MYSQLI_READ_DEFAULT_FILE,/path/to/.my.cnf); /*pass NULL as user/pass so that the values in the config-file are used*/ mysqli_real_connect($mysqli,foo.bar.de,NULL,NULL); ? -- Edit this bug report at http://bugs.php.net/bug.php?id=38144edit=1
Req #34948 [Opn-Tbd]: mysqli_statement and binding array
Edit report at http://bugs.php.net/bug.php?id=34948edit=1 ID: 34948 Updated by: u...@php.net Reported by:max at webscript dot ru Summary:mysqli_statement and binding array -Status: Open +Status: To be documented Type: Feature/Change Request Package:MySQLi related Operating System: WinXP Pro PHP Version:5CVS-2005-10-21 (snap) -Assigned To: +Assigned To:abedford Block user comment: N Private report: N New Comment: Functionality exists as of PHP 5.3.x (x = 0, probably). Not properly documented. MySQLiStatement::get_result() needs to be documented. $m = new mysqli(localhost, root, root); $s = $m-prepare(SELECT ? FROM DUAL); $hello = 'hello'; $s-bind_param(s, $hello); $s-execute(); $r = $s-get_result(); var_dump($r-fetch_all()); Previous Comments: [2005-10-21 17:26:17] max at webscript dot ru Description: Binding array for results of prepared statments in mysqli. Reproduce code: --- now if I want to work with result of prepared statements I should use mysqli_bind_result(). And if i use table with many columns i need to write variable for all this columns : - $stmt = mysqli_prepare($link, SELECT * FROM test_bind_fetch); mysqli_bind_result($stmt, $c1, $c2, $c3, $c4, $c5, $c6, $c7); - I think it would be better to make function mysqli_bind_result_array($stmt, $array, $array_type); Where $stmt - mysqli_statement $array - array, where we will save data from query $array_type = MYSQLI_ASSOC || MYSQLI_NUM || MYSQLI_BOTH I know, that this can be emulated with mysqli_fetch_fileds() + call_user_func_array() but it's not comfortable :-) Expected result: $stmt = mysqli_prepare($link, SELECT * FROM test_bind_fetch); mysqli_bind_result_array($stmt, $row, MYSQLI_ASSOC); mysqli_fetch($stmt); ... now $row will contain data from one record of our query Actual result: -- no result yet -- Edit this bug report at http://bugs.php.net/bug.php?id=34948edit=1
