Req #60354 [Asn]: MYSQL_CLIENT_COMPRESS in php.ini

[uw]

Edit report at https://bugs.php.net/bug.php?id=60354&edit=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=60354&edit=1

Bug #63530 [Opn]: mysqlnd_stmt::bind_one_parameter uses wrong alloc for stmt->param_bind

[uw]

Edit report at https://bugs.php.net/bug.php?id=63530&edit=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 r

Bug #64105 [Opn->Fbk]: Connection err dont work correctly

[uw]

Edit report at https://bugs.php.net/bug.php?id=64105&edit=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:

";
echo 'MySqli Client library version: ' . mysqli_get_client_version() . "";
echo 'MySqli Server version: ' . mysqli_get_client_version() . "";
//===

if (mysqli_connect_errno($mysqli)) {
echo "Connection failed (mode PROC)  MySQL: " . mysqli_connect_error() 
.""; 
} 
echo "";
$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 "";   // (5) comment 
(6) active statement
echo "";

if ($my->connect_errno) {
echo "Connection failed (mode OOP) MySQL: " . $my->connect_error;
} 
echo "";

$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=64105&edit=1

Bug #64870 [Opn->Fbk]: mysqlnd: can't connect to updated MySQL server with old_password Off

[uw]

Edit report at https://bugs.php.net/bug.php?id=64870&edit=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() [mysqli.mysqli]: 
Premature end of data (mysqlnd_wireprotocol.c:553) 
PHP Warning:  mysqli::mysqli() [mysqli.mysqli]: OK 
packet 1 bytes shorter than expected
PHP 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

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:
---
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=64870&edit=1

Req #64844 [Opn->Nab]: PDO::quote() for mysql driver (wrong apostrophe replacing)

[uw]

Edit report at https://bugs.php.net/bug.php?id=64844&edit=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:
---
quote($tmp);

?>

Expected result:

'Let''s go!'

Actual result:
--
'Let\'s go!'






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64844&edit=1

Bug #64875 [Opn->Nab]: Fails if named parameters appears more than once

[uw]

Edit report at https://bugs.php.net/bug.php?id=64875&edit=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:
--
$stmt>execute fails.

Error: SQLSTATE[HY093]: Invalid parameter number







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=64875&edit=1

Bug #61588 [Asn->Nab]: PDOStatement::getColumnMeta returns original table name from view

[uw]

Edit report at https://bugs.php.net/bug.php?id=61588&edit=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 --

' . "\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 . '' . "\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 `script_id` = '057de1e0-
7b48-11e1-8397-60195b7d6275' ORDER BY `url` ASC";
echo $query . '' . "\n";
echo 'When adding the second where clause (using script_id), the Script table 
alias is reported, but MyInstall or my_installs is expected.';
$result = $connection->

Bug #61516 [Opn]: PDOStatement::errorInfo returning NULL for driver code and message

[uw]

Edit report at https://bugs.php.net/bug.php?id=61516&edit=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() [pdo.query]: 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:
---
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=61516&edit=1

Bug #61196 [Opn->Fbk]: Unable to load dynamic library, undefined symbol

[uw]

Edit report at https://bugs.php.net/bug.php?id=61196&edit=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=61196&edit=1

Req #60716 [Opn]: Ability to set PDO connection timeout in milliseconds

[uw]

Edit report at https://bugs.php.net/bug.php?id=60716&edit=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=60716&edit=1

Bug #61411 [Opn]: PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES == FALSE

[uw]

Edit report at https://bugs.php.net/bug.php?id=61411&edit=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:
---
 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=61411&edit=1

Bug #60930 [Opn->Nab]: PDO exec

[uw]

Edit report at https://bugs.php.net/bug.php?id=60930&edit=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=60930&edit=1

Bug #60840 [Asn]: undefined symbol: mysqlnd_debug_std_no_trace_funcs

[uw]

Edit report at https://bugs.php.net/bug.php?id=60840&edit=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=60840&edit=1

Bug #60665 [Opn]: call to empty() on NULL result using PDO::FETCH_LAZY returns false

[uw]

Edit report at https://bugs.php.net/bug.php?id=60665&edit=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=60665&edit=1

Bug #60515 [Opn]: "Invalid parameter number" although it is correct

[uw]

Edit report at https://bugs.php.net/bug.php?id=60515&edit=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=60515&edit=1

Bug #61446 [Opn]: Can't prepare statement without getting a result

[uw]

Edit report at https://bugs.php.net/bug.php?id=61446&edit=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_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_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:
---
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=61446&edit=1

Bug->Req #60849 [Opn]: Too many open links not reported correctly

[uw]

Edit report at https://bugs.php.net/bug.php?id=60849&edit=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=60849&edit=1

Bug #61838 [Opn->Nab]: mysqli_get_cache_stats() does nothing

[uw]

Edit report at https://bugs.php.net/bug.php?id=61838&edit=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=61838&edit=1

Bug #61536 [Opn]: when building with hardening-wrapper, mysqlnd fails with format exceptions

[uw]

Edit report at https://bugs.php.net/bug.php?id=61536&edit=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=61536&edit=1

Req #61520 [Opn->Wfx]: Progress Report + Non-Blocking API

[uw]

Edit report at https://bugs.php.net/bug.php?id=61520&edit=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=61520&edit=1

Bug #61411 [Opn->Csd]: PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES == FALSE

[uw]

Edit report at https://bugs.php.net/bug.php?id=61411&edit=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:
---
 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=61411&edit=1

Bug #55334 [Asn]: MySQLi make mod_php crash on stress test

[uw]

Edit report at https://bugs.php.net/bug.php?id=55334&edit=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:


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=55334&edit=1

Bug #55003 [Opn->Fbk]: PDO prepare() ignores MYSQL_ATTR_USE_BUFFERED_QUERY

[uw]

Edit report at https://bugs.php.net/bug.php?id=55003&edit=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=55003&edit=1

Req #54861 [Opn]: query() optionaly prepared and PDO::PARAM_FIELDNAME(quoting)

[uw]

Edit report at https://bugs.php.net/bug.php?id=54861&edit=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


query_count++;
if(is_array($args)){
if(empty($args)){
$this->sqls[] = 'q: '.$statement;
 

Bug #61536 [Opn->Csd]: when building with hardening-wrapper, mysqlnd fails with format exceptions

[uw]

Edit report at https://bugs.php.net/bug.php?id=61536&edit=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=61536&edit=1

Bug #61837 [Opn]: Problem collecting stats with mysqlnd

[uw]

Edit report at https://bugs.php.net/bug.php?id=61837&edit=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_er

Bug #55737 [Fbk->Nab]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio

[uw]

Edit report at https://bugs.php.net/bug.php?id=55737&edit=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 k

Req #34906 [Asn->Wfx]: mysql: no way to get errno for a failed secondary connection attempt

[uw]

Edit report at https://bugs.php.net/bug.php?id=34906&edit=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 appr

Bug #53970 [Opn->Nab]: PDOStatement::execute returns TRUE even when sql statement is not executed

[uw]

Edit report at https://bugs.php.net/bug.php?id=53970&edit=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=53970&edit=1

Bug #62111 [Opn]: MySQL PDO memory leaks, when used own result row class

[uw]

Edit report at https://bugs.php.net/bug.php?id=62111&edit=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=62111&edit=1

Bug #62111 [Opn]: MySQL PDO memory leaks, when used own result row class

[uw]

Edit report at https://bugs.php.net/bug.php?id=62111&edit=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=62111&edit=1

Bug #62426 [Opn->Nab]: mysqli_fetch_field_direct returns incorrect length on UTF8 fields

[uw]

Edit report at https://bugs.php.net/bug.php?id=62426&edit=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=62426&edit=1

Bug #62054 [Opn->Fbk]: Column size is not reserved for all UNION

[uw]

Edit report at https://bugs.php.net/bug.php?id=62054&edit=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=62054&edit=1

#47782 [Bgs]: Anomalous results from stored procedure with a PREPAREd statement

[uw]

 ID:   47782
 Updated by:   u...@php.net
 Reported By:  phpbug at smithii dot com
 Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Linux, Windows
 PHP Version:  5.2.9, 5.3.0RC2
 New Comment:

Uuupps, accidently changed the Status?

I am quite sure this is not an API issue. Using Prepared Statements
with CALL should be possible a late MySQL 5.0 beta. However, your bug
report made me test some things using the C-API. I ended up filing two
MySQL Server bugs:

http://bugs.mysql.com/bug.php?id=44521
http://bugs.mysql.com/bug.php?id=44495

I suggest we close this report. Most likely you have hit a server issue
and not PHP problem.

Ulf


Previous Comments:


[2009-04-26 15:58:05] phpbug at smithii dot com

j...@php.net: I can call stored procedures just fine with
execute()/bind_result()/fetch(). This is the method the Zend Framework
uses, and I don't want to rewrite their classes. I'm sure there are many
other PHP frameworks that use these functions as well.

Also, the mysqli_multi_query() function does not allow me to prepare()
a statement once, and then execute() it multiple times.

The only problem I'm having, and it's still a problem with PHP 5.3 and
MySQL 5.1, is that if the stored procedure contains a PREPAREd
statement, then the fetch() function is returning corrupted data.

This sure seems to me to be an actual bug, and not just that I'm using
the wrong function call.

Therefore, please mark this bug as open.

I will attempt to fix this myself. Can you point me to any
documentation or IRC channel, that would help me to get started?

Thanks for any assistance,

Ross



[2009-04-26 15:41:48] j...@php.net

For calling stored procedures you have to use mysqli_multi_query.



[2009-04-15 10:09:31] phpbug at smithii dot com

The following script produces errors on 5.2.9 and 5.3.0RC2, on both
Linux and Windows:

 $sql) {
$mysqli->query("DROP PROCEDURE IF EXISTS echo$i");
$mysqli->query($sql) || die($mysqli->error);
$sql = "CALL echo$i(?)";
printf("Executing: %s with '%s'\n", $sql, $inp);
$s = $mysqli->prepare($sql);
if (!$s) die($mysqli->error);
printf("inp=%s (%s)\n", $inp, bin2hex($inp));
$s->bind_param('s', $inp) || die($mysqli->error);
$s->execute() || die($mysqli->error);
$s->bind_result($out) || die($mysqli->error);
while ($s->fetch()) {
   printf("out=%s (%s)\n", $out, bin2hex($out));
}
$s->close();
}

Here's the script's output:

Executing: CALL echo0(?) with '1234'
inp=1234 (31323334)
out=1234 (31323334)
Executing: CALL echo1(?) with '1234'
inp=1234 (31323334)
out=34
(3334)
Executing: CALL echo2(?) with '1234'
inp=1234 (31323334)
out=34
(3334)
Executing: CALL echo3(?) with '1234'
inp=1234 (31323334)
out=3420978 (33343230393738)



[2009-03-26 00:08:39] phpbug at smithii dot com

Description:

Using MySQL 5.0.77, and calling a stored procedure with a PREPAREd
statement, execute()/bind_result()/fetch() return anomalous results.


Reproduce code:
---
Using MySQL 5.0.77, and calling any stored procedure with a PREPAREd
statement, such as:

DROP PROCEDURE IF EXISTS echo;
DELIMITER //
CREATE PROCEDURE echo(p VARCHAR(255))
BEGIN
SET @sql = CONCAT('SELECT ',QUOTE(p));
PREPARE stmt FROM @sql;
EXECUTE stmt;
DROP PREPARE stmt;
END;
//
DELIMITER ;

via this script:

prepare($sql);
$i = $argv[1];
printf("i=%s\n", $i);
$s->bind_param('s', $i);
$s->execute();
$s->bind_result($o);
while ($s->fetch()) {
   printf("o=%s (%s)\n", $o, bin2hex($o));
}
$s->close();

produces anomalous results at least 50% of the time. For example:

$ php echo.php abcd
i=abcd
o=cd  ♦ (636404)

If I remove the PREPAREd statement:

DROP PROCEDURE IF EXISTS echo;
DELIMITER //
CREATE PROCEDURE echo(p VARCHAR(255))
BEGIN
SELECT p;
END;
//
DELIMITER ;

everything works fine.

Replacing execute()/bind_result()/fetch(), with query()/fetch_assoc()
also fixes the issue.

Other details:

mysqli_get_client_info=5.0.51a
mysqli_get_client_version=50051
mysqli_get_server_info=5.0.77-community-nt
mysqli_get_server_version=50077
mysqli_get_host_info=localhost via TCP/IP
mysqli_get_proto_info=10


Expected result:

$ php echo.php abcd
i=abcd
o=abcd (63646566)


Actual result:
--
$ php echo.php abcd
i=abcd
o=cd  ♦ (636404)


--

#45289 [NoF]: Cannot use prepared statements and fetch_row together

[uw]

 ID:   45289
 Updated by:   u...@php.net
 Reported By:  mike dot benza at rice dot edu
 Status:   No Feedback
 Bug Type: MySQLi related
 Operating System: *
 PHP Version:  5.2.4
 New Comment:

I think its bogus. Wrong use of the API. The critical part here is that
you get a result set at all...


Previous Comments:


[2009-05-15 19:55:28] jochen dot wiedmann at gmail dot com

I have checked the latest snapshot (php5.2-200905151830), whether the
problem still persists by using the script below. (Should be easy to
derive a .phpt file from it.)

real_connect("localhost", "root", null, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result() or die($mysqli->error);
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>

Expected output: Something like

- result row ---
Array
(
[0] => int(1)
[1] => string(3) "abc"
)
- no more results ---

Actual output:

- result row ---
Array
(
[0] => 
[1] => 
)
- no more results ---

I'd consider this to be a clear bug.



[2009-05-15 13:39:22] jochen dot wiedmann at gmail dot com

I have the same problem with PHP 5.2.6, as delivered with Fedora 10
Linux.



[2008-07-22 01:00:02] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2008-07-14 21:05:49] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2008-07-11 08:54:43] omolano at PLEASENOSPAMinicia dot es

I've also had this problem. In my case I was trying to use
PDO::FETCH_ASSOC on a prepared statement and the database was SQLite 3
based. I also got null values, like the above poster, not garbage.



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/45289

-- 
Edit this bug report at http://bugs.php.net/?id=45289&edit=1

#48745 [Fbk->Ver]: mysqlnd: mysql_num_fields returns wrong column count for mysql_list_fields

[uw]

 ID:   48745
 Updated by:   u...@php.net
-Summary:  Segmentation fault in MySQL extension with mysqlnd
 Reported By:  theta...@php.net
-Status:   Feedback
+Status:   Verified
 Bug Type: MySQL related
-Operating System: Solaris 10 x86
+Operating System: All
 PHP Version:  5.3.0
 Assigned To:  mysql
 New Comment:

The trouble goes back to an over optimized COM_LIST_FIELDS
communication package and a guess that mysqlnd makes. mysqlnd makes a
guess on the number of fields that the deprecated API call
mysql_list_fields() may return. The guess is never adjusted to the
actual number of fields returned by the Server. As a result
mysql_num_fields(), when invoked with a result set handle returned by
mysql_list_fields(), may return a faulty number of fields. If a users
tries to loop over all fields using the number of fields returned by
mysql_num_fields() as a stop condition, he may try to access fields that
don't exist. The out-of-bound access is not detected because the
internal security check also gets the wrong number of fields reported. 

Workaround:

 - don't use deprecated functions, don't use mysql_list_fields()..
(there is a reason why we want to deprecate COM_LIST_FIELDS!)
 - use libmysql until its fixed


I don't want to play with the packet decoders and the protocol decoding
in the absence of Andrey. I know roughly how to fix, but packet decoding
is for Andrey. Andrey is on vacation until August.

As its easy to work around, I think it can wait.


Previous Comments:


[2009-06-30 20:10:52] theta...@php.net

Here is code to reproduce the bug, it crashes CLI, too:

Just create any database and a table in mysql and run this code on it:

the problematic function is mysql_list_fields() which is deprecated and
does no longer seem to work correct with mysql_field_*() functions.
After I cahnged the code in the Contenido database abstraction to
instead create a dummy query (select * from table limit 1), like it was
done in the Contenido database code for mysqli, it works also with
mysql.

Maybe, if mysqlnd does not support this, mysql_list_fields() should
simply do the same dummy command.






[2009-06-30 18:11:17] theta...@php.net

Hi Johannes,

I am still working on a simple test script. But what I can say is, that
when I changed Contenido's config to use mysqli, it does not crash
anymore.

I found the place where the mysql_field_table is called, but I cannot
see any problems there (this is from the included conlib):

  /* public: return table metadata */
  function metadata($table = "", $full = false) {
$count = 0;
$id= 0;
$res   = array();

/*
 * Due to compatibility problems with Table we changed the
behavior
 * of metadata();
 * depending on $full, metadata returns the following values:
 *
 * - full is false (default):
 * $result[]:
 *   [0]["table"]  table name
 *   [0]["name"]   field name
 *   [0]["type"]   field type
 *   [0]["len"]field length
 *   [0]["flags"]  field flags
 *
 * - full is true
 * $result[]:
 *   ["num_fields"] number of metadata records
 *   [0]["table"]  table name
 *   [0]["name"]   field name
 *   [0]["type"]   field type
 *   [0]["len"]field length
 *   [0]["flags"]  field flags
 *   ["meta"][field name]  index of field named "field name"
 *   This last one could be used if you have a field name, but no
index.
 *   Test:  if (isset($result['meta']['myfield'])) { ...
 */

// if no $table specified, assume that we are working with a query
// result
if ($table) {
  $this->connect();
  $id = @mysql_list_fields($this->Database, $table);
  if (!$id) {
$this->halt("Metadata query failed.");
return false;
  }
} else {
  $id = $this->Query_ID;
  if (!$id) {
$this->halt("No query specified.");
return false;
  }
}

$count = @mysql_num_fields($id);

// made this IF due to performance (one if is faster than $count
if's)
if (!$full) {
  for ($i=0; $i<$count; $i++) {
$res[$i]["table"] = @mysql_field_table ($id, $i);
$res[$i]["name"]  = @mysql_field_name  ($id, $i);
$res[$i]["type"]  = @mysql_field_type  ($id, $i);
$res[$i]["len"]   = @mysql_field_len   ($id, $i);
$res[$i]["flags"] = @mysql_field_flags ($id, $i);
  }
} else { // full
  $res["num_fields"]= $count;

  for ($i=0; $i<$count; $i++) {
$res[$i]["table"] = @mysql_field_table ($id, $i);
$res[$i]["name"]  = @mysql_field_name  ($id, $i);
$res[$i]["type"]  = @mysql_field_type  ($id, $i);
$res[$i]["len"]   = @mysql_field_len   ($id, $i);
$res[$i]["flags"] = @mysql_field_flags ($id, $i);
$res["meta"][$res[$i]["name"]] = $i;
 

#48745 [Ver]: mysqlnd: mysql_num_fields returns wrong column count for mysql_list_fields

[uw]

 ID:   48745
 Updated by:   u...@php.net
 Reported By:  theta...@php.net
 Status:   Verified
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3.0
 Assigned To:  mysql
 New Comment:

Thanks. As said, its fixable, I know the cause, I may know a hack to
fix it but the call is deprecated.  There are zillions of MySQL 4.0
users but we don't support MySQL 4.0 any more. There may be many
list_fields users, but list_fields is deprecated. 

At some point you simply have to stop giving old, deprecated calls the
highest priority.

Apart from that, I don't want to hack with the packet decoders in the
absence of Andrey if the workaround is as easy as: compile ext/mysql
against libmysql (like ever since) and try again in four weeks.

Ulf


Previous Comments:


[2009-07-01 17:14:33] theta...@php.net

As I noted before: This is not my code and there may be a lot of users
installing software using the old mysql extension and also this
function.

For me the workaround was to enable the mysqli configuration option in
Contenido. The only problem is, that it is not enabled per default in
this CMS (although it says: PHP 5 only). Contenido uses a PHP-written
database abstraction (from where I copied the functions in this bug
report) and it was easy to exchange by the other one. It was also
fixable by doing a dummy query "select * from table limit 1" and looking
into the field descriptions for the result set (this is how the
abstraction layer fr mysqli does it in Contenido).

So many thanks for looking at it, I will post a note in the Contenido
mailing list about this problem and the workaround.



[2009-07-01 16:54:38] u...@php.net

The trouble goes back to an over optimized COM_LIST_FIELDS
communication package and a guess that mysqlnd makes. mysqlnd makes a
guess on the number of fields that the deprecated API call
mysql_list_fields() may return. The guess is never adjusted to the
actual number of fields returned by the Server. As a result
mysql_num_fields(), when invoked with a result set handle returned by
mysql_list_fields(), may return a faulty number of fields. If a users
tries to loop over all fields using the number of fields returned by
mysql_num_fields() as a stop condition, he may try to access fields that
don't exist. The out-of-bound access is not detected because the
internal security check also gets the wrong number of fields reported. 

Workaround:

 - don't use deprecated functions, don't use mysql_list_fields()..
(there is a reason why we want to deprecate COM_LIST_FIELDS!)
 - use libmysql until its fixed


I don't want to play with the packet decoders and the protocol decoding
in the absence of Andrey. I know roughly how to fix, but packet decoding
is for Andrey. Andrey is on vacation until August.

As its easy to work around, I think it can wait.



[2009-06-30 20:10:52] theta...@php.net

Here is code to reproduce the bug, it crashes CLI, too:

Just create any database and a table in mysql and run this code on it:

the problematic function is mysql_list_fields() which is deprecated and
does no longer seem to work correct with mysql_field_*() functions.
After I cahnged the code in the Contenido database abstraction to
instead create a dummy query (select * from table limit 1), like it was
done in the Contenido database code for mysqli, it works also with
mysql.

Maybe, if mysqlnd does not support this, mysql_list_fields() should
simply do the same dummy command.






[2009-06-30 18:11:17] theta...@php.net

Hi Johannes,

I am still working on a simple test script. But what I can say is, that
when I changed Contenido's config to use mysqli, it does not crash
anymore.

I found the place where the mysql_field_table is called, but I cannot
see any problems there (this is from the included conlib):

  /* public: return table metadata */
  function metadata($table = "", $full = false) {
$count = 0;
$id= 0;
$res   = array();

/*
 * Due to compatibility problems with Table we changed the
behavior
 * of metadata();
 * depending on $full, metadata returns the following values:
 *
 * - full is false (default):
 * $result[]:
 *   [0]["table"]  table name
 *   [0]["name"]   field name
 *   [0]["type"]   field type
 *   [0]["len"]field length
 *   [0]["flags"]  field flags
 *
 * - full is true
 * $result[]:
 *   ["num_fields"] number of metadata records
 *   [0]["table"]  table name
 *   [0]["name"]   field name
 *   [0]["type"]   field type
 *   [0]["len"]field length
 *   [0]["flags"]  field flags
 *   ["meta"][field name]  index of field named "field name"
 *   This 

#48754 [Opn->Ver]: mysql_close() crash php when no handle specified

[uw]

 ID:   48754
 Updated by:   u...@php.net
-Summary:  mysql_close() crash php
 Reported By:  busia at tiscali dot it
-Status:   Open
+Status:   Verified
 Bug Type: MySQL related
-Operating System: Windows Vista
+Operating System: *
 PHP Version:  5.3.0
-Assigned To:  
+Assigned To:  mysql
 New Comment:

This one is funny. It may have existed since more than one year now and
nobody has ever found it.


Previous Comments:


[2009-07-01 21:59:31] busia at tiscali dot it

1) The sleep function is not needed
2) The connection is successfull

An other information: if I save in $a the mysql_connect return value
and pass it to mysql_close php doesn't crash. In othe words this script
works well:


This instead crashes php:




[2009-07-01 18:04:17] sjoerd-php at linuxonly dot nl

Thank you for your bug report.

I have a couple of questions regarding your bug report:
1. Is the sleep(2) needed to reproduce the bug?
2. Does the database connection succeed? (i.e. what is the return value
of mysql_connect?)



[2009-07-01 12:30:54] busia at tiscali dot it

Description:

This simple code crash php.

This is the Debug diagnostic tool output:

In
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Exception_C005.dmp
the assembly instruction at php_mysql!zif_mysql_close+92 in C:\Program
Files\PHP\ext\php_mysql.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x on thread 0


Report for
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Exception_C005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   PC-UTENTE 
Operating System   Windows Vista Service Pack 1 
Number Of Processors   2 
Process ID   5128 
Process Image   C:\Program Files\PHP\php.exe 
System Up-Time   00:13:11 
Process Up-Time   00:00:02 


Thread 0 - System ID 5132
Entry point   php!mainCRTStartup 
Create time   01/07/2009 14.22.23 
Time spent in user mode   0 Days 0:0:0.31 
Time spent in kernel mode   0 Days 0:0:0.62 






Function Arg 1 Arg 2 Arg 3   Source 
php_mysql!zif_mysql_close+92  02a0d350    

php5ts!zend_do_fcall_common_helper_SPEC+946  02a40070  
  00052fd0
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+130 00c0fbd4 00052fd0  
  00c0fe70
php5ts!execute+29e 02a40070 00052f00 
php5ts!zend_execute_scripts+f6 0008 00052fd0   
 
php5ts!php_execute_script+22d 00c0fe70 00052fd0    

php!main+bf1 0002 00052f68 00051888
php!mainCRTStartup+e3 7ffdb000 00c0ffd4 77bee4b6
kernel32!BaseThreadInitThunk+e 7ffdb000 770bbeaf   
 
ntdll!__RtlUserThreadStart+23 00402d78 7ffdb000    

ntdll!_RtlUserThreadStart+1b 00402d78 7ffdb000    





PHP_MYSQL!ZIF_MYSQL_CLOSE+92In
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Exception_C005.dmp
the assembly instruction at php_mysql!zif_mysql_close+92 in C:\Program
Files\PHP\ext\php_mysql.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x on thread 0

Module Information 
Image Name: C:\Program Files\PHP\ext\php_mysql.dll   Symbol Type:  PDB

Base address: 0x01c3   Time Stamp:  Mon Jun 29 22:24:49 2009  
Checksum: 0x   Comments:  Thanks to Zeev Suraski, Zak Greant,
Georg Richter 
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  MySQL 
ISAPIFilter: False   File Version:  5.3.0 
Managed DLL: False   Internal Name:  MYSQL extension 
VB DLL: False   Legal Copyright:  Copyright © 1997-2009 The PHP Group 
Loaded Image Name:  php_mysql.dll   Legal Trademarks:  PHP 
Mapped Image Name:  C:\Program Files\PHP\ext\php_mysql.dll   Original
filename:  php_mysql.dll 
Module name:  php_mysql   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  44,00 KBytes   Product Version:  5.3.0 
Symbol File Name: 
C:\Users\utente\Desktop\php-debug-pack-5.3.0-Win32-VC6-x86\php_mysql.pdb
  Special Build:  & 




Reproduce code:
---







-- 
Edit this bug report at http://bugs.php.net/?id=48754&edit=1

#48754 [Ver]: mysql_close() crash php when no handle specified

[uw]

 ID:   48754
 Updated by:   u...@php.net
 Reported By:  busia at tiscali dot it
 Status:   Verified
 Bug Type: MySQL related
 Operating System: *
-PHP Version:  5.3.0
+PHP Version:  5.3.0 (as of 21-07-2008)
 Assigned To:  mysql
 New Comment:

Really a great one.

The bug exists since 21-07-2008. That is 11 months and 1 week ago.
Sometimes I which users would try non-GA versions just in case test
suites don't catch issues...

This is when the bug was introduced:
http://cvs.php.net/viewvc.cgi/php-src/ext/mysql/php_mysql.c?r1=1.213.2.6.2.16.2.22&r2=1.213.2.6.2.16.2.23&;

mysql_link points to NULL and that's causing a crash. 

Possible workaround (as suggested by Johannes):

nixn...@linux-en61:~/src/login/php5> cvs diff ext/mysql/tests/
cvs diff: Diffing .
cvs diff: Diffing ext
cvs diff: Diffing ext/mysql
cvs diff: Diffing ext/mysql/tests
nixn...@linux-en61:~/src/login/php5> cvs diff ext/mysql/
cvs diff: Diffing ext/mysql
Index: ext/mysql/php_mysql.c
===
RCS file: /repository/php-src/ext/mysql/php_mysql.c,v
retrieving revision 1.213.2.6.2.16.2.37
diff -r1.213.2.6.2.16.2.37 php_mysql.c
372a373,376
> #ifdef MYSQL_USE_MYSQLND
>   mysqlnd_end_psession(link->conn);
> #endif
>
987,995c991
< #ifdef MYSQL_USE_MYSQLND
<   {
<   int tmp;
<   if ((mysql = zend_list_find(Z_RESVAL_P(mysql_link),
&tmp)) && tmp == le_plink) {
<   mysqlnd_end_psession(mysql->conn);
<   }
<   }
< #endif
<   if (mysql_link) { /* explicit resource number */
---
>   if (mysql_link) {
cvs diff: Diffing ext/mysql/tests


Someone may want to review that.


Previous Comments:


[2009-07-02 13:05:17] u...@php.net

This one is funny. It may have existed since more than one year now and
nobody has ever found it.



[2009-07-01 21:59:31] busia at tiscali dot it

1) The sleep function is not needed
2) The connection is successfull

An other information: if I save in $a the mysql_connect return value
and pass it to mysql_close php doesn't crash. In othe words this script
works well:


This instead crashes php:




[2009-07-01 18:04:17] sjoerd-php at linuxonly dot nl

Thank you for your bug report.

I have a couple of questions regarding your bug report:
1. Is the sleep(2) needed to reproduce the bug?
2. Does the database connection succeed? (i.e. what is the return value
of mysql_connect?)



[2009-07-01 12:30:54] busia at tiscali dot it

Description:

This simple code crash php.

This is the Debug diagnostic tool output:

In
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Exception_C005.dmp
the assembly instruction at php_mysql!zif_mysql_close+92 in C:\Program
Files\PHP\ext\php_mysql.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x on thread 0


Report for
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Exception_C005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   PC-UTENTE 
Operating System   Windows Vista Service Pack 1 
Number Of Processors   2 
Process ID   5128 
Process Image   C:\Program Files\PHP\php.exe 
System Up-Time   00:13:11 
Process Up-Time   00:00:02 


Thread 0 - System ID 5132
Entry point   php!mainCRTStartup 
Create time   01/07/2009 14.22.23 
Time spent in user mode   0 Days 0:0:0.31 
Time spent in kernel mode   0 Days 0:0:0.62 






Function Arg 1 Arg 2 Arg 3   Source 
php_mysql!zif_mysql_close+92  02a0d350    

php5ts!zend_do_fcall_common_helper_SPEC+946  02a40070  
  00052fd0
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+130 00c0fbd4 00052fd0  
  00c0fe70
php5ts!execute+29e 02a40070 00052f00 
php5ts!zend_execute_scripts+f6 0008 00052fd0   
 
php5ts!php_execute_script+22d 00c0fe70 00052fd0    

php!main+bf1 0002 00052f68 00051888
php!mainCRTStartup+e3 7ffdb000 00c0ffd4 77bee4b6
kernel32!BaseThreadInitThunk+e 7ffdb000 770bbeaf   
 
ntdll!__RtlUserThreadStart+23 00402d78 7ffdb000    

ntdll!_RtlUserThreadStart+1b 00402d78 7ffdb000    





PHP_MYSQL!ZIF_MYSQL_CLOSE+92In
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Exception_C005.dmp
the assembly instruction at php_mysql!zif_mysql_close+92 in C:\Program
Files\PHP\ext\php_mysql.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x on t

#48765 [Fbk]: When I use for MYSQLi "load data local infile" Apache 2.2.11 gives out ERROR!

[uw]

 ID:   48765
 Updated by:   u...@php.net
 Reported By:  mypost100 at gmail dot com
 Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Windows XP sp3
 PHP Version:  5.3.0
 New Comment:

Test code would be even better. No "you can download app X from",
please. A simple test is needed. 

Is mysqli_set_local_infile_handler() being used?


Previous Comments:


[2009-07-02 22:00:43] j...@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.

Provide the backtrace, NOTHING else.



[2009-07-02 19:53:58] mypost100 at gmail dot com

File has been loaded completely!
But at once after this, execution of php script is stoped
and "The Apache program has caused an error and will be closed".

Explanation:
Apache and PHP (both) continues normal work (not crashed).

Sending in Microsoft.

Signature of error:
szAppName: httpd.exe  szAppVer: 2.2.11.0  szModName: php5ts.dll 
szModVer: 5.3.0.0  offset: c309

2 files:
httpd.exe.mdmp
appcompat.txt

Content of appcompat.txt:




















http://www.openssl.org/"; PRODUCT_NAME="The OpenSSL Toolkit"
FILE_VERSION="0.9.8i" ORIGINAL_FILENAME="libeay32.dll"
INTERNAL_NAME="libeay32" LEGAL_COPYRIGHT="Copyright © 1998-2005 The
OpenSSL Project. Copyright © 1995-1998 Eric A. Young, Tim J. Hudson. All
rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.9.8.9"
UPTO_BIN_PRODUCT_VERSION="0.9.8.9" LINK_DATE="10/10/2008 04:49:40"
UPTO_LINK_DATE="10/10/2008 04:49:40" VER_LANGUAGE="Àíãëèéñêèé (ÑØÀ)
[0x409]" />




http://www.openssl.org/"; PRODUCT_NAME="The OpenSSL Toolkit"
FILE_VERSION="0.9.8i" ORIGINAL_FILENAME="ssleay32.dll"
INTERNAL_NAME="ssleay32" LEGAL_COPYRIGHT="Copyright © 1998-2005 The
OpenSSL Project. Copyright © 1995-1998 Eric A. Young, Tim J. Hudson. All
rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.9.8.9"
UPTO_BIN_PRODUCT_VERSION="0.9.8.9" LINK_DATE="10/10/2008 05:06:13"
UPTO_LINK_DATE="10/10/2008 05:06:13" VER_LANGUAGE="Àíãëèéñêèé (ÑØÀ)
[0x409]" />










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/48765

-- 
Edit this bug report at http://bugs.php.net/?id=48765&edit=1

#48765 [Opn->Fbk]: When I use for MYSQLi "load data local infile" Apache 2.2.11 gives out ERROR!

[uw]

 ID:   48765
 Updated by:   u...@php.net
 Reported By:  mypost100 at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Windows XP sp3
 PHP Version:  5.3.0
 New Comment:

That's a little connect snippet. Are you saying connect gives the
crash?

If not, it is no proper test code. 


Previous Comments:


[2009-07-03 10:15:32] mypost100 at gmail dot com

I dont use mysqli_set_local_infile_handler().
My connection:
$MYSQLI_CONPR=mysqli_init();
$MYSQLIOPTPR1=mysqli_options($MYSQLI_CONPR,MYSQLI_OPT_LOCAL_INFILE,1);
$MYSQLIRCONPR=mysqli_real_connect($MYSQLI_CONPR,"host","login","pass","db");



[2009-07-03 09:33:20] u...@php.net

Test code would be even better. No "you can download app X from",
please. A simple test is needed. 

Is mysqli_set_local_infile_handler() being used?



[2009-07-02 22:00:43] j...@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.

Provide the backtrace, NOTHING else.



[2009-07-02 19:53:58] mypost100 at gmail dot com

File has been loaded completely!
But at once after this, execution of php script is stoped
and "The Apache program has caused an error and will be closed".

Explanation:
Apache and PHP (both) continues normal work (not crashed).

Sending in Microsoft.

Signature of error:
szAppName: httpd.exe  szAppVer: 2.2.11.0  szModName: php5ts.dll 
szModVer: 5.3.0.0  offset: c309

2 files:
httpd.exe.mdmp
appcompat.txt

Content of appcompat.txt:




















http://www.openssl.org/"; PRODUCT_NAME="The OpenSSL Toolkit"
FILE_VERSION="0.9.8i" ORIGINAL_FILENAME="libeay32.dll"
INTERNAL_NAME="libeay32" LEGAL_COPYRIGHT="Copyright © 1998-2005 The
OpenSSL Project. Copyright © 1995-1998 Eric A. Young, Tim J. Hudson. All
rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.9.8.9"
UPTO_BIN_PRODUCT_VERSION="0.9.8.9" LINK_DATE="10/10/2008 04:49:40"
UPTO_LINK_DATE="10/10/2008 04:49:40" VER_LANGUAGE="Àíãëèéñêèé (ÑØÀ)
[0x409]" />




http://www.openssl.org/"; PRODUCT_NAME="The OpenSSL Toolkit"
FILE_VERSION="0.9.8i" ORIGINAL_FILENAME="ssleay32.dll"
INTERNAL_NAME="ssleay32" LEGAL_COPYRIGHT="Copyright © 1998-2005 The
OpenSSL Project. Copyright © 1995-1998 Eric A. Young, Tim J. Hudson. All
rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0"
VERFILEOS="0x4" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0"
LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.9.8.9"
UPTO_BIN_PRODUCT_VERSION="0.9.8.9" LINK_DATE="10/10/2008 05:06:13"
UPTO_LINK_DATE="10/10/2008 05:06:13" VER_LANGUAGE="Àíãëèéñêèé (ÑØÀ)
[0x409]" />










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/48765

-- 
Edit this bug report at http://bugs.php.net/?id=48765&edit=1

#48373 [Opn->Bgs]: Unable to combine prepared statements and fetch_row

[uw]

 ID:   48373
 Updated by:   u...@php.net
 Reported By:  jochen dot wiedmann at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Fedora Linux 10
 PHP Version:  5.2.9
 New Comment:

After removal of "or die()" for mysqli->use_result, PHP will tell you
that your script is borked:

nixn...@ulflinux:~/src/login/php5> sapi/cli/php  bar.php

Fatal error: Call to a member function fetch_row() on a non-object in
/home/nixnutz/src/login/php5/bar.php on line 23

nixn...@ulflinux:~/src/login/php5> cat bar.php
real_connect("localhost", "root", root, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result();
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>



... and PHP is right. With MySQL Prepared Statements you have to bind
results. There is no way in PHP 5.2.x to get a resultset object from a
statement.



Previous Comments:


[2009-06-05 20:41:09] jochen dot wiedmann at gmail dot com

Ping?



[2009-05-24 15:27:15] jochen dot wiedmann at gmail dot com

Description:

This is a follow up to bug 45289, which has been closed due to missing
feedback. I have checked the latest snapshot (php5.2-200905151830),
whether the problem still persists by using the script below. (Should be
easy to derive a .phpt file from it.)


Reproduce code:
---
real_connect("localhost", "root", null, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result() or die($mysqli->error);
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>


Expected result:

Expected output: Something like

- result row ---
Array
(
[0] => int(1)
[1] => string(3) "abc"
)
- no more results ---


Actual result:
--
Actual output:

- result row ---
Array
(
[0] => 
[1] => 
)
- no more results ---






-- 
Edit this bug report at http://bugs.php.net/?id=48373&edit=1

#48373 [Bgs]: Unable to combine prepared statements and fetch_row

[uw]

 ID:   48373
 Updated by:   u...@php.net
 Reported By:  jochen dot wiedmann at gmail dot com
 Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Fedora Linux 10
 PHP Version:  5.2.9
 New Comment:

After removal of "or die()" for mysqli->use_result, PHP will tell you
that your script is borked:

nixn...@ulflinux:~/src/login/php5> sapi/cli/php  bar.php

Fatal error: Call to a member function fetch_row() on a non-object in
/home/nixnutz/src/login/php5/bar.php on line 23

nixn...@ulflinux:~/src/login/php5> cat bar.php
real_connect("localhost", "root", root, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result();
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>



... and PHP is right. With MySQL Prepared Statements you have to bind
results. There is no way in PHP 5.2.x to get a resultset object from a
statement.



Previous Comments:


[2009-07-03 12:49:10] u...@php.net

After removal of "or die()" for mysqli->use_result, PHP will tell you
that your script is borked:

nixn...@ulflinux:~/src/login/php5> sapi/cli/php  bar.php

Fatal error: Call to a member function fetch_row() on a non-object in
/home/nixnutz/src/login/php5/bar.php on line 23

nixn...@ulflinux:~/src/login/php5> cat bar.php
real_connect("localhost", "root", root, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result();
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>



... and PHP is right. With MySQL Prepared Statements you have to bind
results. There is no way in PHP 5.2.x to get a resultset object from a
statement.




[2009-06-05 20:41:09] jochen dot wiedmann at gmail dot com

Ping?



[2009-05-24 15:27:15] jochen dot wiedmann at gmail dot com

Description:

This is a follow up to bug 45289, which has been closed due to missing
feedback. I have checked the latest snapshot (php5.2-200905151830),
whether the problem still persists by using the script below. (Should be
easy to derive a .phpt file from it.)


Reproduce code:
---
real_connect("localhost", "root", null, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result() or die($mysqli->error);
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>


Expected result:

Expected output: Something like

- res

#48724 [Opn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

[uw]

 ID:   48724
 Updated by:   u...@php.net
 Reported By:  an0nym at narod dot ru
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

Warning

This function is EXPERIMENTAL. The behaviour of this function, its
name, and surrounding documentation may change without notice in a
future release of PHP. This function should be used at your own risk. 

http://de2.php.net/manual/en/pdostatement.getcolumnmeta.php

How can there be a bug if behaviour is undefined?


Previous Comments:


[2009-06-30 15:33:29] an0nym at narod dot ru

Tested - this bug remains actual with PHP 5.3.0 and mysqlnd.



[2009-06-29 18:02:58] an0nym at narod dot ru

Description:

PDOStatement::getColumnMeta() doesn't return native_type for BIT, 
TINYINT and YEAR type columns (these should be 'BIT', 'TINY' and 'YEAR'

respectively). 

This bug was partly discussed within bug #46533, but that bug is 
generally about another thing. 

Reproduce code:
---
$DB=new PDO('mysql:host=localhost;dbname=test','anyone','anyone');
$DB->exec('CREATE TABLE `test`(
 `bit` bit(1)
,`tinyint` tinyint
,`year` year)');
$DB->exec('INSERT INTO `test` VALUES(1,1,2000)');
$statement=$DB->query('SELECT `bit`,`tinyint`,`year` FROM `test`');
$bit=$statement->getColumnMeta(0);
$tinyint=$statement->getColumnMeta(1);
$year=$statement->getColumnMeta(2);
var_dump(isset($bit['native_type']),isset($tinyint['native_type']),isset($year['native_type']));

Expected result:

bool(true) bool(true) bool(true)

Actual result:
--
bool(false) bool(false) bool(false)





-- 
Edit this bug report at http://bugs.php.net/?id=48724&edit=1

#48724 [Opn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

[uw]

 ID:   48724
 Updated by:   u...@php.net
 Reported By:  an0nym at narod dot ru
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

libmysql and mysqlnd behave the same way. If this is decided to be
considered as a bug it is not a mysqlnd bug.







 libmysql ---

nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep -C5
pdo_mysql
PDO

PDO support => enabled
PDO drivers => mysql, sqlite, sqlite2

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => 5.1.35

pdo_sqlite
nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep configure
Configure Command =>  './configure' 
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config'

nixn...@ulflinux:~/src/login/php5> sapi/cli/php pdo.php

int(0)
int(0)
object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(36) "SELECT cbit,ctinyint,cyear FROM test"
}
array(6) {
  ["flags"]=>
  array(0) {
  }
  ["table"]=>
  string(4) "test"
  ["name"]=>
  string(5) "cyear"
  ["len"]=>
  int(4)
  ["precision"]=>
  int(0)
  ["pdo_type"]=>
  int(2)
}
bool(false)
bool(false)
bool(false)
array(1) {
  [0]=>
  array(2) {
["VERSION()"]=>
string(6) "5.1.35"
[0]=>
string(6) "5.1.35"
  }
}


-- mysqlnd 

nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep configure
Configure Command =>  './configure'  '--with-pdo-mysql=mysqlnd'
'--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--enable-debug'
nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep -C5
pdo_mysql
PDO

PDO support => enabled
PDO drivers => mysql, sqlite, sqlite2

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27
$
Persistent cache => enabled
put_hits => 0
--
size => 2000
free_items => 2000
references => 2

Directive => Local Value => Master Value
pdo_mysql.cache_size => 2000 => 2000
pdo_mysql.debug => no value => no value
pdo_mysql.default_socket => /tmp/mysql.sock => /tmp/mysql.sock

pdo_sqlite

PDO Driver for SQLite 3.x => enabled
SQLite Library => 3.6.16
nixn...@ulflinux:~/src/login/php5> sapi/cli/php pdo.php

int(0)
int(0)
object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(36) "SELECT cbit,ctinyint,cyear FROM test"
}
array(6) {
  ["pdo_type"]=>
  int(2)
  ["flags"]=>
  array(0) {
  }
  ["table"]=>
  string(4) "test"
  ["name"]=>
  string(5) "cyear"
  ["len"]=>
  int(4)
  ["precision"]=>
  int(0)
}
bool(false)
bool(false)
bool(false)
array(1) {
  [0]=>
  array(2) {
["VERSION()"]=>
string(6) "5.1.35"
[0]=>
string(6) "5.1.35"
  }
}




Previous Comments:


[2009-07-03 14:13:41] an0nym at narod dot ru

If function has expected behaviour for 35 of 38 cases (that's how many

different types has MySQL), it is rather clear how should it behave for

remaining 3. 

> How can there be a bug if behaviour is undefined? 
Behaviour is not undefined. According to the link you provided, 
behaviour can be changed without notice, but on the moment of writing
it 
is surely defined and has a bug.



[2009-07-03 13:27:23] u...@php.net

Warning

This function is EXPERIMENTAL. The behaviour of this function, its
name, and surrounding documentation may change without notice in a
future release of PHP. This function should be used at your own risk. 

http://de2.php.net/manual/en/pdostatement.getcolumnmeta.php

How can there be a bug if behaviour is undefined?



[2009-06-30 15:33:29] an0nym at narod dot ru

Tested - this bug remains actual with PHP 5.3.0 and mysqlnd.



[2009-06-29 18:02:58] an0nym at narod dot ru

Description:

PDOStatement::getColumnMeta() doesn't return native_type for BIT, 
TINYINT and YEAR type columns (these should be 'BIT', 'TINY' and 'YEAR'

respectively). 

This bug was partly discussed within bug #46533, but that bug is 
generally about another thing. 

Reproduce code:
---
$DB=new PDO('mysql:host=localhost;dbname=test','anyone','anyone');
$DB->exec('CREATE TABLE `test`(
 `bit` bit(1)
,`tinyint` tinyint
,`year` year)');
$DB->exec('INSERT INTO `test` VALUES(1,1,2000)');
$statement=$DB->query('SELECT `bit`,`tinyint`,`year` FROM `test`');
$bit=$statement->getColumnMeta(0);
$tinyint=$statement->getColumnMeta(1);
$year=$statement->getColumnMeta(2);
var_dump(isset($bit['native_type']),isset($tinyint['native_type']),isset($year['native_type']));

Expected result:

bool(true) bool(true) bool(true)

Actual result:
--
bool(false) bool(false) bool(false)





-- 
Edit this bug report at http://bugs.php.net/?id=48724&edit=1

#48724 [Opn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

[uw]

 ID:   48724
 Updated by:   u...@php.net
 Reported By:  an0nym at narod dot ru
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

According to the test behaviour is not to set for certain types. This
is what you get.


Previous Comments:


[2009-07-03 14:28:26] u...@php.net

libmysql and mysqlnd behave the same way. If this is decided to be
considered as a bug it is not a mysqlnd bug.







 libmysql ---

nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep -C5
pdo_mysql
PDO

PDO support => enabled
PDO drivers => mysql, sqlite, sqlite2

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => 5.1.35

pdo_sqlite
nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep configure
Configure Command =>  './configure' 
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config'

nixn...@ulflinux:~/src/login/php5> sapi/cli/php pdo.php

int(0)
int(0)
object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(36) "SELECT cbit,ctinyint,cyear FROM test"
}
array(6) {
  ["flags"]=>
  array(0) {
  }
  ["table"]=>
  string(4) "test"
  ["name"]=>
  string(5) "cyear"
  ["len"]=>
  int(4)
  ["precision"]=>
  int(0)
  ["pdo_type"]=>
  int(2)
}
bool(false)
bool(false)
bool(false)
array(1) {
  [0]=>
  array(2) {
["VERSION()"]=>
string(6) "5.1.35"
[0]=>
string(6) "5.1.35"
  }
}


-- mysqlnd 

nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep configure
Configure Command =>  './configure'  '--with-pdo-mysql=mysqlnd'
'--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--enable-debug'
nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep -C5
pdo_mysql
PDO

PDO support => enabled
PDO drivers => mysql, sqlite, sqlite2

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27
$
Persistent cache => enabled
put_hits => 0
--
size => 2000
free_items => 2000
references => 2

Directive => Local Value => Master Value
pdo_mysql.cache_size => 2000 => 2000
pdo_mysql.debug => no value => no value
pdo_mysql.default_socket => /tmp/mysql.sock => /tmp/mysql.sock

pdo_sqlite

PDO Driver for SQLite 3.x => enabled
SQLite Library => 3.6.16
nixn...@ulflinux:~/src/login/php5> sapi/cli/php pdo.php

int(0)
int(0)
object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(36) "SELECT cbit,ctinyint,cyear FROM test"
}
array(6) {
  ["pdo_type"]=>
  int(2)
  ["flags"]=>
  array(0) {
  }
  ["table"]=>
  string(4) "test"
  ["name"]=>
  string(5) "cyear"
  ["len"]=>
  int(4)
  ["precision"]=>
  int(0)
}
bool(false)
bool(false)
bool(false)
array(1) {
  [0]=>
  array(2) {
["VERSION()"]=>
string(6) "5.1.35"
[0]=>
string(6) "5.1.35"
  }
}





[2009-07-03 14:13:41] an0nym at narod dot ru

If function has expected behaviour for 35 of 38 cases (that's how many

different types has MySQL), it is rather clear how should it behave for

remaining 3. 

> How can there be a bug if behaviour is undefined? 
Behaviour is not undefined. According to the link you provided, 
behaviour can be changed without notice, but on the moment of writing
it 
is surely defined and has a bug.



[2009-07-03 13:27:23] u...@php.net

Warning

This function is EXPERIMENTAL. The behaviour of this function, its
name, and surrounding documentation may change without notice in a
future release of PHP. This function should be used at your own risk. 

http://de2.php.net/manual/en/pdostatement.getcolumnmeta.php

How can there be a bug if behaviour is undefined?



[2009-06-30 15:33:29] an0nym at narod dot ru

Tested - this bug remains actual with PHP 5.3.0 and mysqlnd.



[2009-06-29 18:02:58] an0nym at narod dot ru

Description:

PDOStatement::getColumnMeta() doesn't return native_type for BIT, 
TINYINT and YEAR type columns (these should be 'BIT', 'TINY' and 'YEAR'

respectively). 

This bug was partly discussed within bug #46533, but that bug is 
generally about another thing. 

Reproduce code:
---
$DB=new PDO('mysql:host=localhost;dbname=test','anyone','anyone');
$DB->exec('CREATE TABLE `test`(
 `bit` bit(1)
,`tinyint` tinyint
,`year` year)');
$DB->exec('INSERT INTO `test` VALUES(1,1,2000)');
$statement=$DB->query('SELECT `bit`,`tinyint`,`year` FROM `test`');
$bit=$statement->getColumnMeta(0);
$tinyint=$statement->getColumnMeta(1);
$year=$statement->getColumnMeta(2);
var_dump(isset($bit['native_type']),isset($tinyint['native_type']),isset($year['native_type']));

Expected result:

bool(true) bool(true) bool(true)

Actual result:
--
boo

#48724 [Opn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

[uw]

 ID:   48724
 Updated by:   u...@php.net
 Reported By:  an0nym at narod dot ru
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

You are free to write a patch. 

I refuse to work on stuff that has no specification and which may go
into any direction. That typically ends up in a backwards compatibility
nightmare, which in particular for an abstraction like PDO makes no
sense to me.

The patch may be rather simple. But watch out for different values
returned by different MySQL versions.


Previous Comments:


[2009-07-03 15:39:20] an0nym at narod dot ru

> libmysql and mysqlnd behave the same way. If this is decided to be
considered as a bug it is not a mysqlnd bug. 
I agree. This is not a libmysql or mysqlnd bug. This is a PDO (or 
PDO_MySQL) bug.



[2009-07-03 15:31:27] an0nym at narod dot ru

Tell me then, why MySQLi is OK with all the types while PDO is not? 
Nevertheless, it is not just OK, but it is EQUAL in behaviour for all 
the types except TINYINT, BIT and YEAR. 

Don't tell me, please, MySQLi type and PDO native type refer to 
different things. I'm almost sure they don't. At least they shouldn't.


exec("CREATE TABLE `test`(
 `tinyint` TINYINT NOT NULL
,`smallint` SMALLINT NOT NULL
,`mediumint` MEDIUMINT NOT NULL
,`int` INT NOT NULL
,`bigint` BIGINT NOT NULL
,`decimal` DECIMAL NOT NULL
,`float` FLOAT NOT NULL
,`double` DOUBLE NOT NULL
,`bit` BIT(1) NOT NULL
,`date` DATE NOT NULL
,`datetime` DATETIME NOT NULL
,`timestamp` TIMESTAMP NOT NULL
,`time` TIME NOT NULL
,`year` YEAR NOT NULL
,`char` CHAR(1) NOT NULL
,`varchar` VARCHAR(1) NOT NULL
,`tinytext` TINYTEXT NOT NULL
,`text` TEXT NOT NULL
,`mediumtext` MEDIUMTEXT NOT NULL
,`longtext` LONGTEXT NOT NULL
,`binary` BINARY(1) NOT NULL
,`varbinary` VARBINARY(1) NOT NULL
,`tinyblob` TINYBLOB NOT NULL
,`mediumblob` MEDIUMBLOB NOT NULL
,`blob` BLOB NOT NULL
,`longblob` LONGBLOB NOT NULL
,`enum` ENUM('') NOT NULL
,`set` SET('') NOT NULL)");
$PDO->exec('INSERT INTO `test`(`tinyint`) VALUES(0)');
$PDO_statement=$PDO->query('SELECT * FROM `test`');
$PDO_fields=array();
for($i=0,$n=$PDO_statement->columnCount();$i<$n;++$i){
$PDO_fields[]=$PDO_statement->getColumnMeta($i);
}
$MySQLi=new mysqli('localhost','anyone','anyone','test');
$MySQLi_result=$MySQLi->query('SELECT * FROM `test`');
$MySQLi_fields=$MySQLi_result->fetch_fields();
$bug_fields=array();
for($i=0,$n=count($PDO_fields);$i<$n;++$i){
if(!isset($PDO_fields[$i]['native_type'])
 or 
constant('MYSQLI_TYPE_'.$PDO_fields[$i]['native_type'])!=$MySQLi_field
s[$i]->type){
$bug_fields[]=$PDO_fields[$i]['name'];
}
}
var_dump($bug_fields);
$PDO->exec('DROP TABLE `test`'); ?>



[2009-07-03 14:29:33] u...@php.net

According to the test behaviour is not to set for certain types. This
is what you get.



[2009-07-03 14:28:26] u...@php.net

libmysql and mysqlnd behave the same way. If this is decided to be
considered as a bug it is not a mysqlnd bug.







 libmysql ---

nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep -C5
pdo_mysql
PDO

PDO support => enabled
PDO drivers => mysql, sqlite, sqlite2

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => 5.1.35

pdo_sqlite
nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep configure
Configure Command =>  './configure' 
'--with-pdo-mysql=/usr/local/mysql/bin/mysql_config'

nixn...@ulflinux:~/src/login/php5> sapi/cli/php pdo.php

int(0)
int(0)
object(PDOStatement)#2 (1) {
  ["queryString"]=>
  string(36) "SELECT cbit,ctinyint,cyear FROM test"
}
array(6) {
  ["flags"]=>
  array(0) {
  }
  ["table"]=>
  string(4) "test"
  ["name"]=>
  string(5) "cyear"
  ["len"]=>
  int(4)
  ["precision"]=>
  int(0)
  ["pdo_type"]=>
  int(2)
}
bool(false)
bool(false)
bool(false)
array(1) {
  [0]=>
  array(2) {
["VERSION()"]=>
string(6) "5.1.35"
[0]=>
string(6) "5.1.35"
  }
}


-- mysqlnd 

nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep configure
Configure Command =>  './configure'  '--with-pdo-mysql=mysqlnd'
'--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--enable-debug'
nixn...@ulflinux:~/src/login/php5> sapi/cli/php -i | grep -C5
pdo_mysql
PDO

PDO support => enabled
PDO drivers => mysql, sqlite, sqlite2

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27
$
Persistent cache 

#48724 [Opn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

[uw]

 ID:   48724
 Updated by:   u...@php.net
 Reported By:  an0nym at narod dot ru
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

You are free to patch it. 

Bye.


Previous Comments:


[2009-07-03 16:30:12] an0nym at narod dot ru

Poor MySQLi developers... they've managed to solve this problem without

specification. 

Poor you... you've spent sooo many time for nothing developing this 
function, which works in 35 of 38 cases - this stuff has no 
specification! Wait for a specification - you have a good excuse! 

Bye.



[2009-07-03 16:17:20] u...@php.net

You are free to write a patch. 

I refuse to work on stuff that has no specification and which may go
into any direction. That typically ends up in a backwards compatibility
nightmare, which in particular for an abstraction like PDO makes no
sense to me.

The patch may be rather simple. But watch out for different values
returned by different MySQL versions.



[2009-07-03 15:39:20] an0nym at narod dot ru

> libmysql and mysqlnd behave the same way. If this is decided to be
considered as a bug it is not a mysqlnd bug. 
I agree. This is not a libmysql or mysqlnd bug. This is a PDO (or 
PDO_MySQL) bug.



[2009-07-03 15:31:27] an0nym at narod dot ru

Tell me then, why MySQLi is OK with all the types while PDO is not? 
Nevertheless, it is not just OK, but it is EQUAL in behaviour for all 
the types except TINYINT, BIT and YEAR. 

Don't tell me, please, MySQLi type and PDO native type refer to 
different things. I'm almost sure they don't. At least they shouldn't.


exec("CREATE TABLE `test`(
 `tinyint` TINYINT NOT NULL
,`smallint` SMALLINT NOT NULL
,`mediumint` MEDIUMINT NOT NULL
,`int` INT NOT NULL
,`bigint` BIGINT NOT NULL
,`decimal` DECIMAL NOT NULL
,`float` FLOAT NOT NULL
,`double` DOUBLE NOT NULL
,`bit` BIT(1) NOT NULL
,`date` DATE NOT NULL
,`datetime` DATETIME NOT NULL
,`timestamp` TIMESTAMP NOT NULL
,`time` TIME NOT NULL
,`year` YEAR NOT NULL
,`char` CHAR(1) NOT NULL
,`varchar` VARCHAR(1) NOT NULL
,`tinytext` TINYTEXT NOT NULL
,`text` TEXT NOT NULL
,`mediumtext` MEDIUMTEXT NOT NULL
,`longtext` LONGTEXT NOT NULL
,`binary` BINARY(1) NOT NULL
,`varbinary` VARBINARY(1) NOT NULL
,`tinyblob` TINYBLOB NOT NULL
,`mediumblob` MEDIUMBLOB NOT NULL
,`blob` BLOB NOT NULL
,`longblob` LONGBLOB NOT NULL
,`enum` ENUM('') NOT NULL
,`set` SET('') NOT NULL)");
$PDO->exec('INSERT INTO `test`(`tinyint`) VALUES(0)');
$PDO_statement=$PDO->query('SELECT * FROM `test`');
$PDO_fields=array();
for($i=0,$n=$PDO_statement->columnCount();$i<$n;++$i){
$PDO_fields[]=$PDO_statement->getColumnMeta($i);
}
$MySQLi=new mysqli('localhost','anyone','anyone','test');
$MySQLi_result=$MySQLi->query('SELECT * FROM `test`');
$MySQLi_fields=$MySQLi_result->fetch_fields();
$bug_fields=array();
for($i=0,$n=count($PDO_fields);$i<$n;++$i){
if(!isset($PDO_fields[$i]['native_type'])
 or 
constant('MYSQLI_TYPE_'.$PDO_fields[$i]['native_type'])!=$MySQLi_field
s[$i]->type){
$bug_fields[]=$PDO_fields[$i]['name'];
}
}
var_dump($bug_fields);
$PDO->exec('DROP TABLE `test`'); ?>



[2009-07-03 14:29:33] u...@php.net

According to the test behaviour is not to set for certain types. This
is what you get.



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/48724

-- 
Edit this bug report at http://bugs.php.net/?id=48724&edit=1

#47982 [Asn]: PDO_mysql: Storing image binary data

[uw]

 ID:   47982
 Updated by:   u...@php.net
 Reported By:  markac at home dot pl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: WinXP
 PHP Version:  5.2CVS-2009-04-16 (snap)
 Assigned To:  mysql
 New Comment:

I don't call this a bug.

PDO::PARAM_LOB "can be either textual or binary in nature":

"At some point in your application, you might find that you need to
store "large" data in your database. Large typically means "around 4kb
or more", although some databases can happily handle up to 32kb before
data becomes "large". Large objects can be either textual or binary in
nature. PDO allows you to work with this large data type by using the
PDO::PARAM_LOB  type code in your PDOStatement::bindParam() or
PDOStatement::bindColumn() calls. PDO::PARAM_LOB tells PDO to map the
data as a stream, so that you can manipulate it using the PHP Streams
API.", http://www.php.net/manual/en/pdo.lobs.php

PDO_MySQL threats PDO::PARAM_LOB like textual data. Textual data needs
to be escaped. This is what also happens if you use the PDO Prepared
Statmeent emulation, which has been a default for a long time. When
using the emulation, the column will be seen as textual data and be
escaped. 

This, however, is not a MySQL specific problem. MySQL is affected
because it supports charsets and stuff. But every other PDO driver
supporting charsets is affected as well. 

A proper fix would be to introduce PDO::PARAM_BLOB for use with binary
data. PDO::PARAM_BLOB should go into the PDO core. As changes to the
core can impact all drivers, a volunteer is needed to check and/or
update all drivers to get this PDO flaw fixed.

Ulf



Previous Comments:


[2009-04-22 10:51:40] johan...@php.net

Thanks. Got it now reproduced using 5.2 as well as 5.3 (with both
libmysql and mysqlnd)



[2009-04-21 18:48:05] markac at home dot pl

Only dependant on the SET NAMES.



[2009-04-21 15:10:53] johan...@php.net

I'm not sure I correctly understand your both last messages. Is the
problem only dependant on the SET NAMES call or also on the server
version?

Thanks for clarification.



[2009-04-16 13:33:16] markac at home dot pl

Sorry once again. Works when
$pdo->exec('SET CHARACTER SET utf8');
is commented.



[2009-04-16 13:28:11] markac at home dot pl

Strange, but when I using another remote database server 5.0.66a
everything is good. I thing problem is on my site (bad MySQL or PHP
configuration? ;/).



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/47982

-- 
Edit this bug report at http://bugs.php.net/?id=47982&edit=1

#47387 [Asn->Fbk]: Load stmt result bool false

[uw]

 ID:   47387
 Updated by:   u...@php.net
 Reported By:  lars dot a dot johansson at se dot atlascopco dot com
-Status:   Assigned
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Linux mandriva 2009
 PHP Version:  5.3CVS-2009-02-14 (snap)
 Assigned To:  mysql
 New Comment:

Running the example gives:

bool(true)
array(1) {
  [0]=>
  string(4) "test"
}
bool(true)

Warning: mysqli::query(): (42S22/1054): Unknown column 'APP
LICANT_NO' in 'field list' in
/home/nixnutz/src/login/PHP_5_3/bug47387.php on line 85
bool(false)


Please verify if that is the cause of the bool(false).

A short LOAD DATA test such as the one below does not show any
differences between PHP 5.2 and PHP 5.3 on my box. Would be great, if
you could try that one as well.

$mysqli = new mysqli("127.0.0.1", "root", "root");

$res = $mysqli->query("USE phptest");
printf("USE phptest -> %s\n", var_export($res, true));

$mysqli->query("DROP TABLE IF EXISTS foo");
$res = $mysqli->query("CREATE TABLE IF NOT EXISTS foo (id INT, bar
CHAR(2))");
printf("CREATE TABLE -> %s\n", var_export($res, true));

$file = tempnam(sys_get_temp_dir(), "bug47387");
var_dump($file);
$fp = fopen($file, "w");
fwrite($fp, "1;a\n");
fclose($fp);

$res = $mysqli->query(sprintf("LOAD DATA LOCAL INFILE '%s' INTO TABLE
foo FIELDS TERMINATED BY ';'", $file));
printf("LOAD DATA -> %s\n", var_export($res, true));

$res = $mysqli->query("SELECT * FROM foo");
if ($res)
while ($row = $res->fetch_assoc())
var_dump($row);





Previous Comments:


[2009-02-25 17:13:34] johan...@php.net

I couldn't reproduce using myslqnd and libmysql currently creates other
trouble for me. but I'll investigate. Thanks for the short script so far
:-)



[2009-02-25 15:23:28] lars dot a dot johansson at se dot atlascopco dot
com

Hi,
I can reproduce 'the bug' with attached ugly code. you can use the
infile I supplied earlier. the problem seems a bit tricky.
1 $result = $mysqli->query('CREATE TABLE IF NOT EXISTS ...'
2 $result = $mysqli->query("SHOW WARNINGS", MYSQLI_USE_RESULT...
 this shows one warning:
 Note (1050): Table 'PROJECT_DETAIL' already exists
3 $result->close();
4 Now when I run $result = $mysqli->query(LOAD DATA LOCAL INFILE ...
 then $result is false and I get the warning: 
 //PHP Warning:  mysqli::query(): (0/0): ...
 Note! this only happen in 5.3, in 5.2 $result is true.

Look in the code for the snippet that prevent the 'bug'.

Please let me know if there anything more I can do.

 
  



#!/home/tooljn/PHP5.3/local/bin/php
query($sqlstmt);
var_dump($result);
//if($result) $result->close();
if ($result = $mysqli->query("SELECT DATABASE()")) {
$row = $result->fetch_row();
$result->close();
}
var_dump($row);
$sqlstmt = 'CREATE TABLE IF NOT EXISTS PROJECT_DETAIL
(`PROJECT_DEFINITION` CHAR(24),`DESCRIPTION` CHAR(40),`MASK_ID`
CHAR(24),`RESPONSIBLE_NO` DECIMAL(8,0),`APPLICANT_NO`
DECIMAL(8,0),`COMP_CODE` CHAR(4),`BUS_AREA` CHAR(4),`CONTROLLING_AREA`
CHAR(4),`PROFIT_CTR` CHAR(10),`PROJECT_CURRENCY`
CHAR(5),`PROJECT_CURRENCY_ISO` CHAR(3),`NETWORK_ASSIGNMENT`
DECIMAL(1,0),`START` DATE,`FINISH` DATE,`PLANT` CHAR(4),`CALENDAR`
CHAR(2),`PLAN_BASIC` DECIMAL(1,0),`PLAN_FCST` DECIMAL(1,0),`TIME_UNIT`
CHAR(3),`TIME_UNIT_ISO` CHAR(3),`NETWORK_PROFILE`
CHAR(7),`PROJECT_PROFILE` CHAR(7),`BUDGET_PROFILE`
CHAR(6),`PROJECT_STOCK` CHAR(1),`OBJECTCLASS` CHAR(2),`STATISTICAL`
CHAR(1),`TAXJURCODE` CHAR(15),`INT_PROFILE` CHAR(7),`WBS_SCHED_PROFILE`
CHAR(12),`CSH_BDGT_PROFILE` CHAR(6),`PLAN_PROFILE`
CHAR(6),`JOINT_VENTURE` CHAR(6),`RECOVERY_IND` CHAR(2),`EQUITY_TYPE`
CHAR(3),`JV_OBJECT_TYPE` CHAR(4),`JV_JIB_CLASS`
CHAR(3),`JV_JIB_SUB_CLASS_A` CHAR(5),`DELETION_FLAG`
CHAR(1),`OBJECTCLASS_EXT` CHAR(5),`FUNC_AREA` CHAR(4),`FUNC_AREA_LONG`
CHAR(16)

 ,PRIMARY KEY (`PROJECT_DEFINITION`));';

$result = $mysqli->query($sqlstmt);
var_dump($result);
if($result) {
if ($mysqli->field_count) $result->close();
}
if ($mysqli->warning_count) {
if ($result = $mysqli->query("SHOW WARNINGS", MYSQLI_USE_RESULT)) {
while ($row = $result->fetch_row()) {
printf("%s (%d): %s\n", $row[0], $row[1], $row[2]);
}
}
$result->close();
}

/*
// prevent bug from happen
$result = $mysqli->query('delete from PROJECT_DETAIL where 1=2');
if($result) {
if ($mysqli->field_count) $result->close();
}
if ($mysqli->warning_count) {
if ($result = $mysqli->query("SHOW WARNINGS", MYSQLI_USE_RESULT)) {
while ($row = $result->fetch_row()) {
printf("%s (%d): %s\n", $row[0], $row[1], $row[2]);
}
}
$result->close();
}
// end of bug prevention
*/

$sqlstmt = "LOAD DATA LOCAL INFILE 'PROJECT_DEFINITION_STRU.CSV'
replac

#48857 [Opn->Fbk]: fetch mashes data when Stored Procedure uses prepared statements

[uw]

 ID:   48857
 Updated by:   u...@php.net
 Reported By:  web at sellingpower dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: ubuntu5.6
 PHP Version:  5.2.10
-Assigned To:  
+Assigned To:  mysql
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2009-07-08 21:58:21] web at sellingpower dot com

I misspelled statement in the summary and wanted to correct it for
search purposes.



[2009-07-08 21:54:45] web at sellingpower dot com

Description:

We are using the mysqli extension to interface with MySQL   5.0.51a.  We
are using the prepare/bind_param/execute/bind_result/fetch process
against stored procedures.  When the stored procedure pulls the data via
a prepared statment, fetch mangles the data when putting it into the
bound result variables.

PROCEDURE `p_TestNonPreparedStatement`()

and 

PROCEDURE `p_TestPreparedStatement`()

produce identical results in the query browser but very different
results when run through getresult($stmt,$fields)

Unfortunately, this server is behind a firewall and not accessible to
the public.

All previous bug reports similar to this have identified this behavior
as not a bug without identifying how to get around the problem.

Reproduce code:
---
CREATE definer=`rober...@`` PROCEDURE `p_TestNonPreparedStatement`()
READS SQL DATA
DETERMINISTIC
BEGIN
SELECT * FROM `eBlast`.`veMailList`;

END
--
CREATE definer=`rober...@`` PROCEDURE `p_TestPreparedStatement`()
READS SQL DATA
DETERMINISTIC
BEGIN
DECLARE `new_query` VARCHAR(4096)   DEFAULT '';

SET `new_query` = 'SELECT * FROM `eBlast`.`veMailList`';

SET @new_query = `new_query`;
PREPARE `filtersetlist_query` FROM @new_query;
EXECUTE `filtersetlist_query`;
DEALLOCATE PREPARE `filtersetlist_query`;


END
--
public function pullSendees($status_id,&$fields)
{
$sendees = array();
$DB = new mysqli(DB_SERVER, DB_SERVER_USERNAME, 
DB_SERVER_PASSWORD,
DB_DATABASE_EBLAST);
if (mysqli_connect_errno()) {
throw new Exception('Connection to database failed');
}
$stmt = $DB->stmt_init();

if ($stmt->prepare('CALL `eBlast`.`p_TestNonPreparedStatement`
(?,?)'))
{
$stmt->bind_param('is',$this->id,$status_id);
$stmt->execute();
$sendees = getresult($stmt,$fields);
$stmt->close();
}
$DB->close();
return $sendees;
}

function getresult($stmt,&$fields)
{
$result = array();
$metadata = $stmt->result_metadata();
$fields = $metadata->fetch_fields();
for (;;)
{
$pointers = array();
$row = new stdClass();
$pointers[0] = $stmt;
$count = 1;
foreach ($fields as $field)
{
$fieldname = $field->name;
$pointers[$count] = &$row->$fieldname;
$count++;
}
call_user_func_array('mysqli_stmt_bind_result', $pointers);
if (!mysqli_stmt_fetch($stmt))
break;
foreach ($fields as $field)
{
$fieldname = $field->name;
trigger_error('$' . 'row->' . $fieldname . ' = ' .
$row->$fieldname);
}
$result[] = $row;
}
$metadata->free();
return $result;
}


Expected result:

Prepared Statment Results:

1   1   Robert  Polickoski  
robertpolicko...@sellingpower.com 
Fredericksburg  VA  223 22406-1126  1   1   
6   7   2   1   1   1 
1   1   0   0   1   1   0   0   1   
1   1   1   


Actual result:
--
N

#49058 [Opn->Fbk]: Prepared statements with transaction support

[uw]

 ID:   49058
 Updated by:   u...@php.net
 Reported By:  aphtk at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Ubuntu 9.04
 PHP Version:  5.2.10
-Assigned To:  
+Assigned To:  mysql
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2009-07-25 21:58:56] aphtk at yahoo dot com

Description:

Prepared statements fail but transaction commits other sql inserts and
do not return a failure code.

I am trying to insert to a (innodb) table with unique constraint. 

The 1st time insert proceeds as planned.
On page refresh...
1st sql fails but no failure code is returned
2nd sql proceeds and inserts successfully
3rd sql fails but still no code is rolled back


Reproduce code:
---
$u = new userDAO();
//$u->createNewUser($first_name, $last_name, $username,
$encrypted_passwd, $reminder_question, $reminder_hint);
$u->createNewUser("Anang1", "Phatak1", "anang.pha...@gmail.com", 1,
"quake2", "Is this a test ?", "test");




userDAO.php

_connection = Connection::getConnection("localhost",
"terminator", "terminate"); 
}


public function readUser($username) {
$sql = "SELECT * FROM xt_user_details_vw WHERE username = ?";

if ($stmt = $this->_connection->prepare($sql)) {
$stmt->bind_param("s",$username);
$stmt->execute();
$stmt->store_result();

$meta = $stmt->result_metadata();

$fields = array();
while ($field = $meta->fetch_field()) { 
$fields[] = &$row[$field->name];
}

call_user_func_array(array($stmt, 'bind_result'), 
$fields);

$datagrid = array();
$row_num = 0; 
while ($stmt->fetch()) {
$datagrid[$row_num] = array();
foreach ($row as $k=>$v) {
$datagrid[$row_num][$k] = $v;
}
}
$stmt->free_result();
$stmt->close();
 
return $datagrid;
} 
else {
throw new Exception("Error occured while attempting to 
run user read
query (userDAO.php)","56");
}

}

protected function addNewUserInfo($first_name, $last_name, $username,
$active_flag=1){
$user_insrt_sql = "INSERT INTO xtusers (first_name, last_name,
username, active_flag) VALUES (?, ?, ?, ?)";

try {
if ($stmt = 
$this->_connection->prepare($user_insrt_sql)) {
$stmt->bind_param("sssi", $first_name, 
$last_name, $username,
$active_flag);
$stmt->execute();
$stmt->close();
return $this->_connection->insert_id;
}
else {
throw new Exception("SQL Error");   
}
}
catch (Exception $err) {
$this->_connection->rollback();
echo ($err->getMessage());
throw $err;
}

}

protected function addPasswordInfo($encrypted_passwd) {
$password_insrt_sql = "INSERT INTO xtpasswords (passwd) 
VALUES (?)";
try {
if ($stmt = 
$this->_connection->prepare($password_insrt_sql)) {
$stmt->bind_param("s", $encrypted_passwd);
$stmt->execute();
$stmt->close();
echo ($this->_connection->sqlstate."");
return $this->_connection->insert_id;
}
else {
throw new Exception("SQL Error");

#49287 [Opn->Bgs]: MySQLi client compression broken (mysqlnd)

[uw]

 ID:   49287
 Updated by:   u...@php.net
 Reported By:  shooreek at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: WinXP SP3
 PHP Version:  5.3.0
 New Comment:

Duplicate of http://bugs.php.net/bug.php?id=47017 . Feature request.


Previous Comments:


[2009-08-18 15:14:35] j...@php.net

This is most likely mysqlnd issue since PHP 5.3 binaries for win32 use
mysqlnd.



[2009-08-18 13:57:43] shooreek at gmail dot com

Description:

It seems like mysqli do not understand compression protocol. When you
are using flag MYSQLI_CLIENT_COMPRESS in mysqli_real_connect - it
connects, but can't properly handle server (compressed?) answer.

MySQL server 5.0.67-community-nt-log with compression enabled:

mysql> show variables like '%have_comp%';
+---+---+
| Variable_name | Value |
+---+---+
| have_compress | YES   |
+---+---+
1 row in set (0.00 sec)

I can connect to MySQL server using command line client with flag '-C'
(use compression):

C:\Documents and Settings\U>mysql -C
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 14
Server version: 5.0.67-community-nt-log MySQL Community Edition (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show status like '%compr%';
+---+---+
| Variable_name | Value |
+---+---+
| Compression   | ON|
+---+---+
1 row in set (0.00 sec)

mysql>


I think that something is wrong with mysqli and flag
MYSQLI_CLIENT_COMPRESS

Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) {
die('mysqli_init failed');
}

if (!$mysqli->real_connect('localhost', '', '', NULL, NULL, NULL,
MYSQLI_CLIENT_COMPRESS)) {
die('Connect Error (' . mysqli_connect_errno() . ') '
. mysqli_connect_error());
}
$mysqli->query("show status like '%compre%'");
$mysqli->close();


Expected result:

Normal query execution without any errors.

Actual result:
--
PHP
Some times it crushes. Sometimes it do not.
Error log:

PHP Warning:  mysqli::query(): MySQL server has gone away in
C:\Documents and Settings\U\Desktop\compress_test.php on line 42
PHP Warning:  mysqli::query(): Error reading result set's header in
C:\Documents and Settings\U\Desktop\compress_test.php on line 42

MySQL
Error log:

090818 17:36:04 [Warning] Aborted connection 8 to db: 'unconnected'
user: 'U' host: 'localhost' (Got a packet bigger than
'max_allowed_packet' bytes)

someimes:

090818 17:31:13 [Warning] Aborted connection 61 to db: 'unconnected'
user: 'U' host: 'localhost' (Got an error reading communication packets)





-- 
Edit this bug report at http://bugs.php.net/?id=49287&edit=1

#49357 [Opn->Ver]: MySQLi extension fails to recognize POINT (spatial) colums

[uw]

 ID:   49357
 Updated by:   u...@php.net
 Reported By:  phpbug at r-o-b-e-r-t dot de
-Status:   Open
+Status:   Verified
 Bug Type: MySQLi related
 Operating System: Debian/Ubuntu/Gentoo
 PHP Version:  5.2.10
-Assigned To:  
+Assigned To:  mysql
 New Comment:

Works with mysqlnd, fails with libmysql. Missing type in mysqli_api.c:

@@ -373,6 +373,9 @@
 #ifdef FIELD_TYPE_NEWDECIMAL
case MYSQL_TYPE_NEWDECIMAL:
 #endif
+#ifdef FIELD_TYPE_GEOMETRY
+   case MYSQL_TYPE_GEOMETRY:
+#endif



Previous Comments:


[2009-08-25 20:01:02] bugs at r-o-b-e-r-t dot de

Sorry for my double-posting of the same bug.


But I got everytime an error, that the headers already was sent. So i
tried several times to submit my bug, and did not recognize, that it was
already submitted.

SORRY!!


regards

 - Robert



[2009-08-25 14:55:11] phpbug at r-o-b-e-r-t dot de

Description:

As reported in Bug "#37671 MySQLi extension fails to recognize BIT
colums" I have the same problem with a Spatial Column.

The Column coord is a POINT Field.



Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
 `coord` point default NULL,
) ENGINE=InnoDB

The Test Code:

// $mysqli is an existing db connection

$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
  debug_zval_dump($res);
  var_dump($res);
}
$stmt->close();

Expected result:

The binary representation of the point

Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)

Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL






-- 
Edit this bug report at http://bugs.php.net/?id=49357&edit=1

#49308 [Asn]: random crashes on freeing mysqli result storage

[uw]

 ID:   49308
 Updated by:   u...@php.net
 Reported By:  f4ckm5 at web dot de
 Status:   Assigned
 Bug Type: MySQLi related
 Operating System: Windows Server 2003 SP2 32Bit
 PHP Version:  5.3, 6 (2009-08-22)
 Assigned To:  mysql
 New Comment:

Any chance to provide a test script? I know its hard, but its also hard
to say anything based on the backtrace and without a reproducible test
case.

Thanks,
Ulf


Previous Comments:


[2009-08-21 09:31:38] f4ckm5 at web dot de

I used the latest Snapshot 5.3.1-dev from Thu Aug 20 15:19:10 2009

The crashes became less frequent. Instead of 10 in 5 Minutes i caught
only 5 in 3.5 hours. But the crashes still occur:

#

Thread 250 - System ID 9828
Entry point   msvcrt!_endthreadex+2f 
Create time   21.08.2009 09:11:23 
Time spent in user mode   0 Days 0:0:0.171 
Time spent in kernel mode   0 Days 0:0:0.78 


Function Arg 1 Arg 2 Arg 3   Source 
php5ts!_zend_mm_free_int+139 056cf838 00050004 00720336   

php5ts!_efree+36 012296e8 06894910 00725877
php5ts!_zval_ptr_dtor+66 068948e4 006ad310 06868980
php5ts!zend_hash_destroy+27 06876538 06868980 015a1665
php5ts!zend_object_std_dtor+2b 06868980 056ce490 06868980  
 
php_mysqli!mysqli_objects_free_storage+25 06868980 056ce490
05a733e4
php_mysqli!mysqli_result_free_storage+28 06868980 056ce490
056ce490
php5ts!zend_objects_store_del_ref_by_handle_ex+1b6 002b
015b1600 056ce490
php5ts!zend_objects_store_del_ref+1e 06868960 056ce490

php5ts!_zval_dtor_func+76 06868960  05ab9050
php5ts!ZEND_ASSIGN_SPEC_CV_VAR_HANDLER+237 0546fbfc 056ce490   
 0546fe78
php5ts!execute+29e 05ab9050 056ce400 
php5ts!zend_execute_scripts+f6 0008 056ce490   
 
php5ts!php_execute_script+22d 0546fe78 056ce490 0003   

php5apache2_2!php_handler+5d0 012c18b8 00615988 012c18b8   

libhttpd!ap_run_handler+21 012c18b8 012c18b8 012c18b8
libhttpd!ap_invoke_handler+ae  012bc860 0546ff3c   

libhttpd!ap_die+29e 012c18b8  0065fb90
libhttpd!ap_get_request_note+1ccc 012bc860 012bc860
012bc860
libhttpd!ap_run_process_connection+21 012bc860 0062b108
0546ff84
libhttpd!ap_process_connection+33 012bc860 012b1820

libhttpd!ap_regkey_value_remove+c7c 012bc858 

msvcrt!_endthreadex+a3 012a7d08  
kernel32!BaseThreadStart+34 77b9b4bc 012a7d08 


PHP5TS!_ZEND_MM_FREE_INT+139In
httpd__PID__7192__Date__08_21_2009__Time_09_11_24AM__898__First chance
exception 0XC005.dmp the assembly instruction at
php5ts!_zend_mm_free_int+139 in C:\PHP\php5ts.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x02080174 on thread 250

Module Information 
Image Name: C:\PHP\php5ts.dll
Symbol Type:  PDB 
Base address: 0x006a
Time Stamp:  Thu Aug 20 15:19:10 2009  
Checksum: 0x
Comments:   
COM DLL: False
Company Name:  The PHP Group 
ISAPIExtension: False
File Description:  PHP Script Interpreter 
ISAPIFilter: False
File Version:  5.3.1-dev 
Managed DLL: False
Internal Name:  PHP Script Interpreter 
VB DLL: False
Legal Copyright:  Copyright © 1997-2009 The PHP Group 
Loaded Image Name:  php5ts.dll
Legal Trademarks:  PHP 
Mapped Image Name:  C:\PHP\php5ts.dll
Original filename:  php5ts.dll 
Module name:  php5ts
Private Build:   
Single Threaded:  False
Product Name:  PHP 
Module Size:  5,45 MBytes
Product Version:  5.3.1-dev 
Symbol File Name:  C:\Dokumente und
Einstellungen\Administrator.HML\Desktop\php-debug-pack-5.3-win32-VC6-x86-latest\php5ts.pdb
Special Build:  &



[2009-08-20 09:53:08] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-08-20 09:12:50] f4ckm5 at web dot de

Description:

PHP Crashes on Freeing Mysqli Result Storage.
It happens randomly on our production machine, when the Server is under
medium to heavy load.
I did a Win32 backtrace and captured 10 crashes in merely 5 minutes,
each causing the apache httpd.exe worker process to restart.


Reproduce code:
---
I happens randomly under greater server load. I could not pin the error
to some lines of code. It happens with all the 5.3 builds I tested
official 5.3.0 as well as latest snapshot.
It does not happen with 5.2.x at all.

Expected result:
-

#48745 [Asn->Csd]: mysqlnd: mysql_num_fields returns wrong column count for mysql_list_fields

[uw]

 ID:   48745
 Updated by:   u...@php.net
 Reported By:  theta...@php.net
-Status:   Assigned
+Status:   Closed
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-29
 Assigned To:  mysql
 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.

Next attempt... I hope this time its really fixed :). Please try again,
thanks!


Previous Comments:


[2009-08-29 13:11:41] theta...@php.net

It is still the same stack trace:

Program terminated with signal 11, Segmentation fault.
#0  0xfc3931aa in php_mysql_field_info (ht=0, return_value=0xd7db5a8,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, 
tsrm_ls=0xc96f228, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
2410Z_STRLEN_P(return_value) =
strlen(mysql_field->table);
(gdb) where
#0  0xfc3931aa in php_mysql_field_info (ht=0, return_value=0xd7db5a8,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, 
tsrm_ls=0xc96f228, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
#1  0xfc56d291 in zend_do_fcall_common_helper_SPEC
(execute_data=0xc6ddf20, tsrm_ls=0xc404e20)
at /pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:313
#2  0xfc56c116 in execute (op_array=0xc7dcaec, tsrm_ls=0xc404e20) at
/pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:104
#3  0xfc54a437 in zend_execute_scripts (type=8, tsrm_ls=0xc404e20,
retval=0x0, file_count=3)
at /pangaea/install/php5.3-200908291030/Zend/zend.c:1188
#4  0xfc4f58d6 in php_execute_script (primary_file=0xe7de7cb8,
tsrm_ls=0xc404e20)
at /pangaea/install/php5.3-200908291030/main/main.c:2212
#5  0xfc5d60ea in php5_execute (pb=0x81ae228, sn=0xc2661dc,
rq=0xc266254)
at /pangaea/install/php5.3-200908291030/sapi/nsapi/nsapi.c:1047
#6  0xfecfb147 in func_exec_str () from
/pangaea/webserver70/lib/libns-httpd40.so
#7  0xfecfbd2a in INTfunc_exec_directive () from
/pangaea/webserver70/lib/libns-httpd40.so
#8  0xfed009d6 in INTservact_service () from
/pangaea/webserver70/lib/libns-httpd40.so
#9  0xfed01a39 in INTservact_handle_processed () from
/pangaea/webserver70/lib/libns-httpd40.so
#10 0xfed5e358 in __1cLHttpRequestUUnacceleratedRespond6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#11 0xfed5d5ba in __1cLHttpRequestNHandleRequest6MpnGnetbuf_I_i_ ()
from /pangaea/webserver70/lib/libns-httpd40.so
#12 0xfed5be90 in __1cNDaemonSessionDrun6M_v_ () from
/pangaea/webserver70/lib/libns-httpd40.so
#13 0xfeb861fc in ThreadMain () from
/pangaea/webserver70/lib/libnsprwrap.so
#14 0xfe0bb6c9 in _pt_root () from
/pangaea/webserver70/lib/libnspr4.so
#15 0xfd37fd36 in _thr_setup () from /lib/libc.so.1
#16 0xfd380020 in L3_doit () from /lib/libc.so.1
#17 0xeb9d3c00 in ?? ()
#18 0x in ?? ()
(gdb) print *mysql_field
$2 = {name = 0x0, org_name = 0x0, table = 0x0, org_table = 0x0, db =
0x0, catalog = 0x0, def = 0x0, length = 0, max_length = 0, 
  name_length = 0, org_name_length = 0, table_length = 0,
org_table_length = 0, db_length = 0, catalog_length = 0, def_length = 0,

  flags = 0, decimals = 0, charsetnr = 0, type = MYSQL_TYPE_DECIMAL,
root = 0x0, root_len = 0}
(gdb) print mysql_result
$3 = (MYSQLND_RES *) 0x0
(gdb) 

The new version is installed (I checked the snaps.php.net version for
your changes).

The attached PHP scipt to reproduce generates similar stack trace:

Core was generated by `php test.php'.
Program terminated with signal 11, Segmentation fault.
#0  0x081a24f2 in php_mysql_field_info (ht=0, return_value=0x887e28c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, 
tsrm_ls=0x8b057d8, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
2410Z_STRLEN_P(return_value) =
strlen(mysql_field->table);
(gdb) where
#0  0x081a24f2 in php_mysql_field_info (ht=0, return_value=0x887e28c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, 
tsrm_ls=0x8b057d8, entry_type=2) at
/pangaea/install/php5.3-200908291030/ext/mysql/php_mysql.c:2410
#1  0x0837c5d9 in zend_do_fcall_common_helper_SPEC
(execute_data=0x8abb468, tsrm_ls=0x885ecc0)
at /pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:313
#2  0x0837b45e in execute (op_array=0x886e340, tsrm_ls=0x885ecc0) at
/pangaea/install/php5.3-200908291030/Zend/zend_vm_execute.h:104
#3  0x0835977f in zend_execute_scripts (type=8, tsrm_ls=0x885ecc0,
retval=0x0, file_count=3)
at /pangaea/install/php5.3-200908291030/Zend/zend.c:1188
#4  0x08304c1e in php_execute_script (primary_file=0x8047c90,
tsrm_ls=0x885ecc0)
at /pangaea/install/php5.3-200908291030/main/main.c:2212
#5  0x083e5406 in main (argc=2, argv=0x8047d24

#49357 [Ver->Tbd]: MySQLi extension fails to recognize POINT (spatial) colums

[uw]

 ID:   49357
 Updated by:   u...@php.net
 Reported By:  phpbug at r-o-b-e-r-t dot de
-Status:   Verified
+Status:   To be documented
 Bug Type: MySQLi related
 Operating System: Debian/Ubuntu/Gentoo
 PHP Version:  5.2.10
 Assigned To:  mysql
 New Comment:

This has been fixed in PHP 5_3 and trunk (PHP 6). 

Please note the SVN commit message. In the worst case ext/mysqli used
together with the MySQL Client Library will allocate a huge result
buffer of 4GB to hold as little as 25 bytes needed to represent a
POINT(1, 1) in binary format.


Previous Comments:


[2009-09-11 13:38:48] s...@php.net

Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=288267
Log: Fix for bug #49357  (MySQLi extension fails to recognize POINT
(spatial) colums).

Do yourself a favour and use mysqlnd. mysqlnd has no isuses here.

If you insist on using the MySQL Client Library (libmysql) I strongly
recommend to use mysqli_stmt_store_result() when fetching geometry data
using prepared statements. When streaming data, which is the default for
prepared statements, ext/mysqli will have to make a guess on the size of
the result buffer it needs. The guess is based on a length reported by
the MySQL CLient Library (libmysql). The MySQL Client Library reports
4GB (!) for a POINT - a conservative and safe guess. Consequently,
ext/mysqli will try to allocate 4GB of RAM. The true (maximum) size of
the column is not available before buffering the result on the client
using mysqli_stmt_store_result(). If you call
mysqli_stmt_store_result(), the result buffers will not get bigger than
needed. However, store_result()/buffering is usually not what you want
when you ask for prepared statements.



[2009-08-26 10:34:25] u...@php.net

Works with mysqlnd, fails with libmysql. Missing type in mysqli_api.c:

@@ -373,6 +373,9 @@
 #ifdef FIELD_TYPE_NEWDECIMAL
case MYSQL_TYPE_NEWDECIMAL:
 #endif
+#ifdef FIELD_TYPE_GEOMETRY
+   case MYSQL_TYPE_GEOMETRY:
+#endif




[2009-08-25 20:01:02] bugs at r-o-b-e-r-t dot de

Sorry for my double-posting of the same bug.


But I got everytime an error, that the headers already was sent. So i
tried several times to submit my bug, and did not recognize, that it was
already submitted.

SORRY!!


regards

 - Robert



[2009-08-25 14:55:11] phpbug at r-o-b-e-r-t dot de

Description:

As reported in Bug "#37671 MySQLi extension fails to recognize BIT
colums" I have the same problem with a Spatial Column.

The Column coord is a POINT Field.



Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
 `coord` point default NULL,
) ENGINE=InnoDB

The Test Code:

// $mysqli is an existing db connection

$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
  debug_zval_dump($res);
  var_dump($res);
}
$stmt->close();

Expected result:

The binary representation of the point

Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)

Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL






-- 
Edit this bug report at http://bugs.php.net/?id=49357&edit=1

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

Note: MYSQL_OPT_READ_TIMEOUT != MYSQL_OPT_CONNECT_TIMEOUT . 

What you are saying is that you query times out. The report is not
about a connection timeout. Your timeout happens after the connection
has been established and therefore setting MYSQLI_OPT_CONNECT_TIMEOUT
won't change anything.

In the end ext/mysqli is a wrapper of the MySQL C API and thus we can
consult the C API documentation on the difference. The docs at
http://dev.mysql.com/doc/refman/5.1/en/mysql-options.html explain:

MYSQL_OPT_CONNECT_TIMEOUT (argument type: unsigned int *)
Connect timeout in seconds.

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)

The timeout in seconds for attempts to read from the server. Each
attempt uses this timeout value and there are retries if necessary, so
the total effective timeout value is three times the option value. You
can set the value so that a lost connection can be detected earlier than
the TCP/IP Close_Wait_Timeout value of 10 minutes. This option works
only for TCP/IP connections and, prior to MySQL 5.1.12, only for
Windows.

MYSQL_OPT_READ_TIMEOUT has never been supported by ext/mysqli. You can
easily check that by "grepping" through the source of ext/mysqli as
contained in, for example, PHP 5.2.10. 

nixn...@ulflinux:~/ftp/php-5.2.10> grep -i -R MYSQL_OPT_READ_TIMEOUT
ext/
nixn...@ulflinux:~/ftp/php-5.2.10> grep -i -R MYSQLI_OPT_READ_TIMEOUT
ext/
nixn...@ulflinux:~/ftp/php-5.2.10>

However, mysqlnd is not the MySQL Client Library, mysqlnd makes use of
PHP Streams. Looks like PHP Streams use different default timeouts than
the MySQL Client Library on Windows. That is a problem for you as a
user, no doubt. 

Question is how to solve that problem.


Previous Comments:


[2009-09-09 19:49:41] j...@php.net

See also bug #49436



[2009-09-09 12:54:30] casper at procurios dot nl

I found a workaround:

Apparently mysqlnd does listen to 'default_socket_timeout'.

ini_set('default_socket_timeout', 5) sets a 5 second limit

I found that ini_set('default_socket_timeout', -1) disables the timeout
all 
together, though that might be undocumented behaviour.


$storeTimeout = ini_set('default_socket_timeout', -1);
$link = mysqli_init();
mysqli_real_connect($link, 'localhost', 'root', '', 'mysql', null,
null, 
MYSQLI_CLIENT_INTERACTIVE);
ini_set('default_socket_timeout', $storeTimeout);

mysqli_query($link, 'SELECT SLEEP(62)');

mysqli_close($link);



[2009-09-09 12:24:02] casper at procurios dot nl

Description:

It seems that mysqli using mysqlnd has a set timeout of 60 seconds for

a query. If you run a query that takes longer, the 'MySQL server has 
gone away' error is cast.

Furthermore when I try to set MYSQLI_OPT_CONNECT_TIMEOUT, it won't 
comply.

In the reproduce code below, I get the errors only after 60 seconds, 
where I expected to see them at 5 seconds.


Reproduce code:
---
$link = mysqli_init();
mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5);
mysqli_real_connect($link, 'localhost', 'root', '');

mysqli_query($link, 'SELECT SLEEP(62)');

mysqli_close($link);

Actual result:
--
PHP Warning:  mysqli_query(): MySQL server has gone away in 
/home/casper/mysqltest.php on line 7

Warning: mysqli_query(): MySQL server has gone away in 
/home/casper/mysqltest.php on line 7
PHP Warning:  mysqli_query(): Error reading result set's header in 
/home/casper/mysqltest.php on line 7

Warning: mysqli_query(): Error reading result set's header in 
/home/casper/mysqltest.php on line 7






-- 
Edit this bug report at http://bugs.php.net/?id=49511&edit=1

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

On the available options on Windows:

ext/mysql, ext/mysqli and PDO_MYSQL can either be compiled against the
MySQL Client Library or mysqlnd. That is also true for Windows in
general. If not, it is a bug. Windows users do have a choice.

Pierre, php.net restricts itself on Windows to mysqlnd for a reason.
The reason is that you cannot compile current versions of the MySQL
Client Library using Visual Studio 6, just like you cannot compile
current versions of the MySQL Server using Visual Studio 6. Visual
Studio 6 is old - it is from 1998. As far as I know, Microsoft has
stopped to support this compiler. Consequently, MySQL has dropped
support for it.

To my understanding VC 6 is still of relevance for php.net because
other projects have or still do use VC 6. I would not want to use an
unsupported compiler for my project but they do although there are
superior and free offering from Microsoft. Using their products together
with a PHP binary that is not compiled with VC 6 can lead to crashes. 

Therefore, you are looking to support VC 6, which is not possible when
using the MySQL Client Library.

If one fails to use a recent version of the MySQL Client Library
together with ext/mysql, ext/mysqli or PDO_MYSQL on Windows using a
recent Visual Studio it should be reported as a bug.


Previous Comments:


[2009-09-15 14:12:51] paj...@php.net

It is not correct to say that mysqlnd on windows differs from
libmysql.

Libmysql uses native APIs directly no matter the platform while mysqlnd
always uses php's stream, on every platform.

The different between windows and unix is that windows relies on
mysqlnd only (no choice, no compatible library available). 



[2009-09-15 13:34:28] u...@php.net

Note: MYSQL_OPT_READ_TIMEOUT != MYSQL_OPT_CONNECT_TIMEOUT . 

What you are saying is that you query times out. The report is not
about a connection timeout. Your timeout happens after the connection
has been established and therefore setting MYSQLI_OPT_CONNECT_TIMEOUT
won't change anything.

In the end ext/mysqli is a wrapper of the MySQL C API and thus we can
consult the C API documentation on the difference. The docs at
http://dev.mysql.com/doc/refman/5.1/en/mysql-options.html explain:

MYSQL_OPT_CONNECT_TIMEOUT (argument type: unsigned int *)
Connect timeout in seconds.

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)

The timeout in seconds for attempts to read from the server. Each
attempt uses this timeout value and there are retries if necessary, so
the total effective timeout value is three times the option value. You
can set the value so that a lost connection can be detected earlier than
the TCP/IP Close_Wait_Timeout value of 10 minutes. This option works
only for TCP/IP connections and, prior to MySQL 5.1.12, only for
Windows.

MYSQL_OPT_READ_TIMEOUT has never been supported by ext/mysqli. You can
easily check that by "grepping" through the source of ext/mysqli as
contained in, for example, PHP 5.2.10. 

nixn...@ulflinux:~/ftp/php-5.2.10> grep -i -R MYSQL_OPT_READ_TIMEOUT
ext/
nixn...@ulflinux:~/ftp/php-5.2.10> grep -i -R MYSQLI_OPT_READ_TIMEOUT
ext/
nixn...@ulflinux:~/ftp/php-5.2.10>

However, mysqlnd is not the MySQL Client Library, mysqlnd makes use of
PHP Streams. Looks like PHP Streams use different default timeouts than
the MySQL Client Library on Windows. That is a problem for you as a
user, no doubt. 

Question is how to solve that problem.



[2009-09-09 19:49:41] j...@php.net

See also bug #49436



[2009-09-09 12:54:30] casper at procurios dot nl

I found a workaround:

Apparently mysqlnd does listen to 'default_socket_timeout'.

ini_set('default_socket_timeout', 5) sets a 5 second limit

I found that ini_set('default_socket_timeout', -1) disables the timeout
all 
together, though that might be undocumented behaviour.


$storeTimeout = ini_set('default_socket_timeout', -1);
$link = mysqli_init();
mysqli_real_connect($link, 'localhost', 'root', '', 'mysql', null,
null, 
MYSQLI_CLIENT_INTERACTIVE);
ini_set('default_socket_timeout', $storeTimeout);

mysqli_query($link, 'SELECT SLEEP(62)');

mysqli_close($link);



[2009-09-09 12:24:02] casper at procurios dot nl

Description:

It seems that mysqli using mysqlnd has a set timeout of 60 seconds for

a query. If you run a query that takes longer, the 'MySQL server has 
gone away' error is cast.

Furthermore when I try to set M

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

Pierre,

1) is an aside discussion. 

I assume 2) is about binaries offered for download from mysql.com? CRT
is a runtime dependency specific to the Windows platform. Windows
binaries can have those dependencies. Educate me about the details but
if any Windows binary has such a dependency there can be trouble using
it with other Windows binaries that use other CRTs.

In the worst case users needs to compile the library from source. 

Now, if you compile the MySQL Client Library from source to ensure that
it uses the CRT you want and that self-compiled library cannot be used
together with ext/mysql, ext/mysqli or PDO_MYSQL, it is a bug and should
be reported - at bugs.php.net or at bugs.mysql.com.


Previous Comments:


[2009-09-15 15:32:59] paj...@php.net

It canont be compiled against libmysql. Their libraries are not
compatible. I don't choose to do it but they did. I also reported the
issue upstream but they don't care much about this problem, for two
reasons:

1. they gave php a new driver so they won't worry anymore about such
troubles (or licensing issues)
2. libmysql latest version CRT (5.0 or 5.1) can only be built only for
vc8+

There is even BC breaks as latest libmysql.dll makes php 5.2 crashes.

But that's not the problem here, there is a bug in mysqlnd and it has
to be addressed. It is not even a windows only issue.



[2009-09-15 15:18:27] u...@php.net

On the available options on Windows:

ext/mysql, ext/mysqli and PDO_MYSQL can either be compiled against the
MySQL Client Library or mysqlnd. That is also true for Windows in
general. If not, it is a bug. Windows users do have a choice.

Pierre, php.net restricts itself on Windows to mysqlnd for a reason.
The reason is that you cannot compile current versions of the MySQL
Client Library using Visual Studio 6, just like you cannot compile
current versions of the MySQL Server using Visual Studio 6. Visual
Studio 6 is old - it is from 1998. As far as I know, Microsoft has
stopped to support this compiler. Consequently, MySQL has dropped
support for it.

To my understanding VC 6 is still of relevance for php.net because
other projects have or still do use VC 6. I would not want to use an
unsupported compiler for my project but they do although there are
superior and free offering from Microsoft. Using their products together
with a PHP binary that is not compiled with VC 6 can lead to crashes. 

Therefore, you are looking to support VC 6, which is not possible when
using the MySQL Client Library.

If one fails to use a recent version of the MySQL Client Library
together with ext/mysql, ext/mysqli or PDO_MYSQL on Windows using a
recent Visual Studio it should be reported as a bug.



[2009-09-15 14:12:51] paj...@php.net

It is not correct to say that mysqlnd on windows differs from
libmysql.

Libmysql uses native APIs directly no matter the platform while mysqlnd
always uses php's stream, on every platform.

The different between windows and unix is that windows relies on
mysqlnd only (no choice, no compatible library available). 



[2009-09-15 13:34:28] u...@php.net

Note: MYSQL_OPT_READ_TIMEOUT != MYSQL_OPT_CONNECT_TIMEOUT . 

What you are saying is that you query times out. The report is not
about a connection timeout. Your timeout happens after the connection
has been established and therefore setting MYSQLI_OPT_CONNECT_TIMEOUT
won't change anything.

In the end ext/mysqli is a wrapper of the MySQL C API and thus we can
consult the C API documentation on the difference. The docs at
http://dev.mysql.com/doc/refman/5.1/en/mysql-options.html explain:

MYSQL_OPT_CONNECT_TIMEOUT (argument type: unsigned int *)
Connect timeout in seconds.

MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)

The timeout in seconds for attempts to read from the server. Each
attempt uses this timeout value and there are retries if necessary, so
the total effective timeout value is three times the option value. You
can set the value so that a lost connection can be detected earlier than
the TCP/IP Close_Wait_Timeout value of 10 minutes. This option works
only for TCP/IP connections and, prior to MySQL 5.1.12, only for
Windows.

MYSQL_OPT_READ_TIMEOUT has never been supported by ext/mysqli. You can
easily check that by "grepping" through the source of ext/mysqli as
contained in, for example, PHP 5.2.10. 

nixn...@ulflinux:~/ftp/php-5.2.10> grep -i -R MYSQL_OPT_READ_TIMEOUT
ext/
nixn...@ulflinux:~/ftp/php-5.2.10> grep -i -R MY

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

On the bug itself:

The MySQL Client Library (libmysql) sets a limit of 365 * 24 * 3600
seconds as a default timeout for select() etc. One will hardly ever get
into that timeout but see a TCP/IP timeout happening before (e.g. after
10 minutes). 

mysqlnd does currently set no PHP streams timeout and therefore the
default PHP setting applies. 

To get the same behaviour in mysql as with libmysql, we would need to
set the streams timeout to 1 year upon connect and wait. We may wait
longer than max_execution_time. However, it seems that by default
default_socket_timeout > max_execution_time and thus it may be
irrelevant to take care of it.

Only ext/mysqli is more or less prepared to allow users to set the
timeout via an API call - one would need to introduce
MYSQLI_READ_TIMEOUT. While it may be easy to add that option also to
PDO_MYSQL there is easy way to make the read timeout configurable via
API in ext/mysql.

My current thinking is to introduce mysqlnd.read_timeout with a default
value equal to libmysql (= huug) and make it SYSTEM_INI
only: no API changes required and admins can set it to
max_execution_time if they want.

Regarding default_socket_timeout = -1 -> endless:
I could not find it in the documentation either. It may need
documentation.


Previous Comments:


[2009-09-15 16:45:05] u...@php.net

Pierre,

1) is an aside discussion. 

I assume 2) is about binaries offered for download from mysql.com? CRT
is a runtime dependency specific to the Windows platform. Windows
binaries can have those dependencies. Educate me about the details but
if any Windows binary has such a dependency there can be trouble using
it with other Windows binaries that use other CRTs.

In the worst case users needs to compile the library from source. 

Now, if you compile the MySQL Client Library from source to ensure that
it uses the CRT you want and that self-compiled library cannot be used
together with ext/mysql, ext/mysqli or PDO_MYSQL, it is a bug and should
be reported - at bugs.php.net or at bugs.mysql.com.



[2009-09-15 15:32:59] paj...@php.net

It canont be compiled against libmysql. Their libraries are not
compatible. I don't choose to do it but they did. I also reported the
issue upstream but they don't care much about this problem, for two
reasons:

1. they gave php a new driver so they won't worry anymore about such
troubles (or licensing issues)
2. libmysql latest version CRT (5.0 or 5.1) can only be built only for
vc8+

There is even BC breaks as latest libmysql.dll makes php 5.2 crashes.

But that's not the problem here, there is a bug in mysqlnd and it has
to be addressed. It is not even a windows only issue.



[2009-09-15 15:18:27] u...@php.net

On the available options on Windows:

ext/mysql, ext/mysqli and PDO_MYSQL can either be compiled against the
MySQL Client Library or mysqlnd. That is also true for Windows in
general. If not, it is a bug. Windows users do have a choice.

Pierre, php.net restricts itself on Windows to mysqlnd for a reason.
The reason is that you cannot compile current versions of the MySQL
Client Library using Visual Studio 6, just like you cannot compile
current versions of the MySQL Server using Visual Studio 6. Visual
Studio 6 is old - it is from 1998. As far as I know, Microsoft has
stopped to support this compiler. Consequently, MySQL has dropped
support for it.

To my understanding VC 6 is still of relevance for php.net because
other projects have or still do use VC 6. I would not want to use an
unsupported compiler for my project but they do although there are
superior and free offering from Microsoft. Using their products together
with a PHP binary that is not compiled with VC 6 can lead to crashes. 

Therefore, you are looking to support VC 6, which is not possible when
using the MySQL Client Library.

If one fails to use a recent version of the MySQL Client Library
together with ext/mysql, ext/mysqli or PDO_MYSQL on Windows using a
recent Visual Studio it should be reported as a bug.



[2009-09-15 14:12:51] paj...@php.net

It is not correct to say that mysqlnd on windows differs from
libmysql.

Libmysql uses native APIs directly no matter the platform while mysqlnd
always uses php's stream, on every platform.

The different between windows and unix is that windows relies on
mysqlnd only (no choice, no compatible library available). 



[2009-09-

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

Pierre, 

I already stated that MySQL does no longer support VC6. MySQL does not
support VC6 because Microsoft itself does not support it. 

Who to blame? It depends on how you feel about VC6 being EOL'd. If you
think it should not have been EOL'd, you need to blame both Microsoft
and users of Microsoft products, such as MySQL. 

If you consider the EOL of VC6 as reasonable, the root cause of the VC6
trouble is neither Microsoft nor MySQL. The trouble is caused by those
who still use VC6 for their binaries and/or do not make their source
compile with recent versions of Visual Studio and therefore cause
incompatibilities.

Not supporting VC6 is not a bug, it is a feature decision. Not
supporting compilers which are out of maintenance, is a pretty sane
policy in my eyes considering lack of vendor support, lack of bug fixes,
lack of support for modern hardware. VC6 is from the same generation as
GCC 2.8.0. I wonder how many of us bother about GCC 2.8.0 ...

For every reasonable current (no GCC 2.8 no VC6!) environment the
availability of a binary (here: libmysql) is unrelated to the question
if a software can be used. I am sure that there are Linux systems which
use a glibc (stdc++, etc. ) that is not compatible with the glibc used
to build a certain software. This does not necessarily mean that you
cannot use the software altogether. As a last resort you can always try
to compile it yourself on the target platform.

I am aware how inconvenient it is for php.net to build tons of
libraries from source. Any request for a pre-compiled binary that uses
CRT x.y is as valid as a request for glibc x.y. It is good and correct
to precisely repeat any build request - preferably at bugs.mysql.com.
This is the best place to make MySQL do anything for you.

Anyway, I still cannot believe that it is *impossible* to the the MySQL
Client Library together with ext/mysqli, ext/mysql or PDO_MYSQL. 

If you have any problems compiling the MySQL Client Library from source
using a recent version of Visual Studio, please report it as a bug on
bugs.mysql.com. If any of those self-compiled libraries cannot be used
because of faulty coding leading to stinky run-time dependencies, please
report it as a bug on bugs.mysql.com. If you think the code of the
extensions needs to be tweaked to be compatible with any such binary,
please report it as a bug on bugs.php.net or bugs.mysql.com.


Previous Comments:


[2009-09-16 07:30:33] casper at procurios dot nl

Hi Ulf,

Your solution seems spot on.

Also, I don't understand what you are saying here:
"To get the same behaviour in mysql as with libmysql, we would need to
set the streams timeout to 1 year upon connect and 
wait. We may wait longer than max_execution_time. However, it seems
that by default default_socket_timeout >  
max_execution_time and thus it may be irrelevant to take care of it."

In the manual on set_time_limit() it says:
"Note: The set_time_limit() function and the configuration directive
max_execution_time only affect the execution time of 
the script itself. Any time spent on activity that happens outside the
execution of the script such as system calls using 
system(), stream operations, database queries, etc. is not included
when determining the maximum time that the script has 
been running. This is not true on Windows where the measured time is
real." (http://www.php.net/manual/en/function.set-time-
limit.php)

Regarding default_socket_timeout = -1 -> endless:
It could be that it's just overflowing an int, resulting in 2^64-1 or
2^32-1 seconds.



[2009-09-15 20:59:16] paj...@php.net

Sorry, I was not clear. Bugs have been reported and nothing has been
done so far. It is not a PHP bug and no, the libmysql libraries (5.0 or
5.1) does not build with VC6 either. As I said, we rather have to fix
mysqlnd instead of forking libmysql for our usages (as we will have to
do to support VC6).

I really don't want to do that for the next 3-4 years (expected
lifetime for 5.3) :)

And yes, your comment about this bug is right, Ulf agrees too afaics :)



[2009-09-15 17:23:06] u...@php.net

On the bug itself:

The MySQL Client Library (libmysql) sets a limit of 365 * 24 * 3600
seconds as a default timeout for select() etc. One will hardly ever get
into that timeout but see a TCP/IP timeout happening before (e.g. after
10 minutes). 

mysqlnd does currently set no PHP streams timeout and therefore the
default PHP setting applies. 

To get the same behaviour in mysql as with libmysql, we would need to
set the stream

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

Any bug reports on libmysql crashes we could work on?


Previous Comments:


[2009-09-16 12:04:47] paj...@php.net

I'm not blaming anyone, I'm only saying that we can forget libmysql on
windows, no matter which compiler we use as the crashes occur too with
the other versions.

Now, it seems that you insist that we should use libmysql. Does it mean
that mysqlnd is not usable or will not be usable in a production
environment in a reasonable time frame (aka 5.3.1)? No irony meant here,
but if it is the case then we have a serious problem to solve.



[2009-09-16 11:46:38] u...@php.net

Pierre, 

I already stated that MySQL does no longer support VC6. MySQL does not
support VC6 because Microsoft itself does not support it. 

Who to blame? It depends on how you feel about VC6 being EOL'd. If you
think it should not have been EOL'd, you need to blame both Microsoft
and users of Microsoft products, such as MySQL. 

If you consider the EOL of VC6 as reasonable, the root cause of the VC6
trouble is neither Microsoft nor MySQL. The trouble is caused by those
who still use VC6 for their binaries and/or do not make their source
compile with recent versions of Visual Studio and therefore cause
incompatibilities.

Not supporting VC6 is not a bug, it is a feature decision. Not
supporting compilers which are out of maintenance, is a pretty sane
policy in my eyes considering lack of vendor support, lack of bug fixes,
lack of support for modern hardware. VC6 is from the same generation as
GCC 2.8.0. I wonder how many of us bother about GCC 2.8.0 ...

For every reasonable current (no GCC 2.8 no VC6!) environment the
availability of a binary (here: libmysql) is unrelated to the question
if a software can be used. I am sure that there are Linux systems which
use a glibc (stdc++, etc. ) that is not compatible with the glibc used
to build a certain software. This does not necessarily mean that you
cannot use the software altogether. As a last resort you can always try
to compile it yourself on the target platform.

I am aware how inconvenient it is for php.net to build tons of
libraries from source. Any request for a pre-compiled binary that uses
CRT x.y is as valid as a request for glibc x.y. It is good and correct
to precisely repeat any build request - preferably at bugs.mysql.com.
This is the best place to make MySQL do anything for you.

Anyway, I still cannot believe that it is *impossible* to the the MySQL
Client Library together with ext/mysqli, ext/mysql or PDO_MYSQL. 

If you have any problems compiling the MySQL Client Library from source
using a recent version of Visual Studio, please report it as a bug on
bugs.mysql.com. If any of those self-compiled libraries cannot be used
because of faulty coding leading to stinky run-time dependencies, please
report it as a bug on bugs.mysql.com. If you think the code of the
extensions needs to be tweaked to be compatible with any such binary,
please report it as a bug on bugs.php.net or bugs.mysql.com.



[2009-09-16 07:30:33] casper at procurios dot nl

Hi Ulf,

Your solution seems spot on.

Also, I don't understand what you are saying here:
"To get the same behaviour in mysql as with libmysql, we would need to
set the streams timeout to 1 year upon connect and 
wait. We may wait longer than max_execution_time. However, it seems
that by default default_socket_timeout >  
max_execution_time and thus it may be irrelevant to take care of it."

In the manual on set_time_limit() it says:
"Note: The set_time_limit() function and the configuration directive
max_execution_time only affect the execution time of 
the script itself. Any time spent on activity that happens outside the
execution of the script such as system calls using 
system(), stream operations, database queries, etc. is not included
when determining the maximum time that the script has 
been running. This is not true on Windows where the measured time is
real." (http://www.php.net/manual/en/function.set-time-
limit.php)

Regarding default_socket_timeout = -1 -> endless:
It could be that it's just overflowing an int, resulting in 2^64-1 or
2^32-1 seconds.



[2009-09-15 20:59:16] paj...@php.net

Sorry, I was not clear. Bugs have been reported and nothing has been
done so far. It is not a PHP bug and no, the libmysql libraries (5.0 or
5.1) does not build with VC6 either. As I said, we rather have to fix
mysqlnd instead of forking libmysql for our usages (as we will have to
do to 

#49511 [Asn]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

For the public and on "libmysql not compatible": Pierre and I had an
argue on IRC. While we still disagree in some points we concluded it
would be benefitial to document some background information for users -
either in the docs or on the wiki.

On the bug itself: I am waiting for Andrey to review a patch.


Previous Comments:


[2009-09-16 12:13:45] u...@php.net

Any bug reports on libmysql crashes we could work on?



[2009-09-16 12:04:47] paj...@php.net

I'm not blaming anyone, I'm only saying that we can forget libmysql on
windows, no matter which compiler we use as the crashes occur too with
the other versions.

Now, it seems that you insist that we should use libmysql. Does it mean
that mysqlnd is not usable or will not be usable in a production
environment in a reasonable time frame (aka 5.3.1)? No irony meant here,
but if it is the case then we have a serious problem to solve.



[2009-09-16 11:46:38] u...@php.net

Pierre, 

I already stated that MySQL does no longer support VC6. MySQL does not
support VC6 because Microsoft itself does not support it. 

Who to blame? It depends on how you feel about VC6 being EOL'd. If you
think it should not have been EOL'd, you need to blame both Microsoft
and users of Microsoft products, such as MySQL. 

If you consider the EOL of VC6 as reasonable, the root cause of the VC6
trouble is neither Microsoft nor MySQL. The trouble is caused by those
who still use VC6 for their binaries and/or do not make their source
compile with recent versions of Visual Studio and therefore cause
incompatibilities.

Not supporting VC6 is not a bug, it is a feature decision. Not
supporting compilers which are out of maintenance, is a pretty sane
policy in my eyes considering lack of vendor support, lack of bug fixes,
lack of support for modern hardware. VC6 is from the same generation as
GCC 2.8.0. I wonder how many of us bother about GCC 2.8.0 ...

For every reasonable current (no GCC 2.8 no VC6!) environment the
availability of a binary (here: libmysql) is unrelated to the question
if a software can be used. I am sure that there are Linux systems which
use a glibc (stdc++, etc. ) that is not compatible with the glibc used
to build a certain software. This does not necessarily mean that you
cannot use the software altogether. As a last resort you can always try
to compile it yourself on the target platform.

I am aware how inconvenient it is for php.net to build tons of
libraries from source. Any request for a pre-compiled binary that uses
CRT x.y is as valid as a request for glibc x.y. It is good and correct
to precisely repeat any build request - preferably at bugs.mysql.com.
This is the best place to make MySQL do anything for you.

Anyway, I still cannot believe that it is *impossible* to the the MySQL
Client Library together with ext/mysqli, ext/mysql or PDO_MYSQL. 

If you have any problems compiling the MySQL Client Library from source
using a recent version of Visual Studio, please report it as a bug on
bugs.mysql.com. If any of those self-compiled libraries cannot be used
because of faulty coding leading to stinky run-time dependencies, please
report it as a bug on bugs.mysql.com. If you think the code of the
extensions needs to be tweaked to be compatible with any such binary,
please report it as a bug on bugs.php.net or bugs.mysql.com.



[2009-09-16 07:30:33] casper at procurios dot nl

Hi Ulf,

Your solution seems spot on.

Also, I don't understand what you are saying here:
"To get the same behaviour in mysql as with libmysql, we would need to
set the streams timeout to 1 year upon connect and 
wait. We may wait longer than max_execution_time. However, it seems
that by default default_socket_timeout >  
max_execution_time and thus it may be irrelevant to take care of it."

In the manual on set_time_limit() it says:
"Note: The set_time_limit() function and the configuration directive
max_execution_time only affect the execution time of 
the script itself. Any time spent on activity that happens outside the
execution of the script such as system calls using 
system(), stream operations, database queries, etc. is not included
when determining the maximum time that the script has 
been running. This is not true on Windows where the measured time is
real." (http://www.php.net/manual/en/function.set-time-
limit.php)

Regarding default_socket_timeout = -1 -> endless:
It could be that it's just overflowing an int, resulting in 2^64-1 o

#49511 [Asn->Tbd]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
-Status:   Assigned
+Status:   To be documented
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 Assigned To:  mysql
 New Comment:

It should be fixed now, please test a SVN snapshot.

We may want to stress out in the documentation that a) users cannot set
MYSQL_OPT_READ_TIMEOUT through an API call and, if we ever allow setting
it, there may be subtle differences between libmysql and streams how to
interpret the value of MYSQL_OPT_READ_TIMEOUT. 

Using mysqlnd means using PHP streams. PHP streams documentation needs
to be consulted on such details not dev.mysql.com documentation on the
MySQL Client Library AKA libmysql AKA C-API.


Previous Comments:


[2009-09-16 15:00:54] s...@php.net

Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=288378
Log: Fix and tests for bug #49511 . mysqlnd and the MySQL Client
Library (libmysql) use different networking APIs. mysqlnd does use PHP
streams whereas libmysql uses its own wrapper of the operating level
network calls. PHP sets by default a read timeout of 60s for streams -
php.ini, default_socket_timeout. This default applies to all streams
that set no other timeout value. mysqlnd has not set any other value and
therefore it connections of long running queries can have been cut off
after default_socket_timeout seconds resulting in a 2006 - MySQL Server
has gone away error message. The MySQL Client Library sets a default
timeout of 365 * 24 * 3600 seconds (1year) and waits for other timeouts
to happen, e.g. TCP/IP timeouts. mysqlnd now uses the same very long
timeout. The value is configurable through a new php.ini setting:
mysqlnd.net_read_timeout. mysqlnd.net_read_timeout gets used by any
extension (ext/mysql, ext/mysqli, PDO_MySQL) that uses mysqlnd. mysqlnd
tells PHP Streams to use mysqlnd.net_read_timeout. Please note that
there may be subtle differences between MYSQL_OPT_READ_TIMEOUT from the
MySQL Client Library and PHP Streams. E.g. MYSQL_OPT_READ_TIMEOUT is
documented to work only for TCP/IP connections and, prior to MySQL
5.1.2, only for Windows. PHP streams may not have this limitation.
Please check the streams documentation, if in doubt.



[2009-09-16 13:43:06] u...@php.net

For the public and on "libmysql not compatible": Pierre and I had an
argue on IRC. While we still disagree in some points we concluded it
would be benefitial to document some background information for users -
either in the docs or on the wiki.

On the bug itself: I am waiting for Andrey to review a patch.



[2009-09-16 12:13:45] u...@php.net

Any bug reports on libmysql crashes we could work on?



[2009-09-16 12:04:47] paj...@php.net

I'm not blaming anyone, I'm only saying that we can forget libmysql on
windows, no matter which compiler we use as the crashes occur too with
the other versions.

Now, it seems that you insist that we should use libmysql. Does it mean
that mysqlnd is not usable or will not be usable in a production
environment in a reasonable time frame (aka 5.3.1)? No irony meant here,
but if it is the case then we have a serious problem to solve.



[2009-09-16 11:46:38] u...@php.net

Pierre, 

I already stated that MySQL does no longer support VC6. MySQL does not
support VC6 because Microsoft itself does not support it. 

Who to blame? It depends on how you feel about VC6 being EOL'd. If you
think it should not have been EOL'd, you need to blame both Microsoft
and users of Microsoft products, such as MySQL. 

If you consider the EOL of VC6 as reasonable, the root cause of the VC6
trouble is neither Microsoft nor MySQL. The trouble is caused by those
who still use VC6 for their binaries and/or do not make their source
compile with recent versions of Visual Studio and therefore cause
incompatibilities.

Not supporting VC6 is not a bug, it is a feature decision. Not
supporting compilers which are out of maintenance, is a pretty sane
policy in my eyes considering lack of vendor support, lack of bug fixes,
lack of support for modern hardware. VC6 is from the same generation as
GCC 2.8.0. I wonder how many of us bother about GCC 2.8.0 ...

For every reasonable current (no GCC 2.8 no VC6!) environment the
availability of a binary (here: libmysql) is unrelated to the question
if a software can be used. I am sure that there are Linux systems which
use a glibc (stdc++, etc. ) that is not compatible with the glibc used
to build a certain software. This does not necess

#49511 [Tbd]: mysqlnd timeout seems fixed at 60 secs

[uw]

 ID:   49511
 Updated by:   u...@php.net
 Reported By:  casper at procurios dot nl
 Status:   To be documented
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3, 6 (2009-09-09)
 New Comment:

Regarding default_socket_timeout = -1 -> endless:

I don't think it is an overflow. I only glimpsed over the code and saw
that sometimes an extra check is made for -1 to convert it into NULL.
And NULL means endless, see
http://msdn.microsoft.com/en-us/library/ms740141%28VS.85%29.aspx or,
same on Linux, man select. 


Previous Comments:


[2009-09-16 15:05:51] u...@php.net

It should be fixed now, please test a SVN snapshot.

We may want to stress out in the documentation that a) users cannot set
MYSQL_OPT_READ_TIMEOUT through an API call and, if we ever allow setting
it, there may be subtle differences between libmysql and streams how to
interpret the value of MYSQL_OPT_READ_TIMEOUT. 

Using mysqlnd means using PHP streams. PHP streams documentation needs
to be consulted on such details not dev.mysql.com documentation on the
MySQL Client Library AKA libmysql AKA C-API.



[2009-09-16 15:00:54] s...@php.net

Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=288378
Log: Fix and tests for bug #49511 . mysqlnd and the MySQL Client
Library (libmysql) use different networking APIs. mysqlnd does use PHP
streams whereas libmysql uses its own wrapper of the operating level
network calls. PHP sets by default a read timeout of 60s for streams -
php.ini, default_socket_timeout. This default applies to all streams
that set no other timeout value. mysqlnd has not set any other value and
therefore it connections of long running queries can have been cut off
after default_socket_timeout seconds resulting in a 2006 - MySQL Server
has gone away error message. The MySQL Client Library sets a default
timeout of 365 * 24 * 3600 seconds (1year) and waits for other timeouts
to happen, e.g. TCP/IP timeouts. mysqlnd now uses the same very long
timeout. The value is configurable through a new php.ini setting:
mysqlnd.net_read_timeout. mysqlnd.net_read_timeout gets used by any
extension (ext/mysql, ext/mysqli, PDO_MySQL) that uses mysqlnd. mysqlnd
tells PHP Streams to use mysqlnd.net_read_timeout. Please note that
there may be subtle differences between MYSQL_OPT_READ_TIMEOUT from the
MySQL Client Library and PHP Streams. E.g. MYSQL_OPT_READ_TIMEOUT is
documented to work only for TCP/IP connections and, prior to MySQL
5.1.2, only for Windows. PHP streams may not have this limitation.
Please check the streams documentation, if in doubt.



[2009-09-16 13:43:06] u...@php.net

For the public and on "libmysql not compatible": Pierre and I had an
argue on IRC. While we still disagree in some points we concluded it
would be benefitial to document some background information for users -
either in the docs or on the wiki.

On the bug itself: I am waiting for Andrey to review a patch.



[2009-09-16 12:13:45] u...@php.net

Any bug reports on libmysql crashes we could work on?



[2009-09-16 12:04:47] paj...@php.net

I'm not blaming anyone, I'm only saying that we can forget libmysql on
windows, no matter which compiler we use as the crashes occur too with
the other versions.

Now, it seems that you insist that we should use libmysql. Does it mean
that mysqlnd is not usable or will not be usable in a production
environment in a reasonable time frame (aka 5.3.1)? No irony meant here,
but if it is the case then we have a serious problem to solve.



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/49511

-- 
Edit this bug report at http://bugs.php.net/?id=49511&edit=1

#49442 [Asn->Csd]: Some queries crash PHP with mysqli_real_connect()

[uw]

 ID:   49442
 Updated by:   u...@php.net
 Reported By:  vr...@php.net
-Status:   Assigned
+Status:   Closed
 Bug Type: MySQLi related
 Operating System: Windows
 PHP Version:  5.3.0
 Assigned To:  mysql
 New Comment:

A patch has been committed to fix the problem. Please try the latest
SVN snapshots.

The bug affects all operating systems. It is a mysqlnd bug. In theory
it should be possible to cause the crash using any MySQL API that uses
mysqlnd: ext/mysql, ext/mysqli, PDO_MYSQL. 

The crash happens both with connections created using mysqli_init() +
mysqli_real_connect() and mysqli_connect("p:", ...).




Previous Comments:


[2009-09-16 17:03:45] s...@php.net

Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=288379
Log: Fix (by Andrey) and test for bug #49442 . Don't use efree() for
memory allocated with malloc()... If a connection gets created by
mysqli_init(), mysqlnd makes it 'persistent'. 'Persistent' means that
mysqlnd uses malloc(). mysqlnd does use malloc() instead of ealloc()
because it is unknown if the connection will become a true persistent
connection in the sense of ext/mysqli. It is unknown if the user wants a
persistent connection or not until the user calls mysqli_real_connect().
To avoid tricky conversions mysqlnd uses malloc(), which sets a private
persistent flag in the mysqlnd structures. A precondition for the crash
to happen was that the private persistent flag is set. The flag is also
set when creating a real persistent connection (in the sense of
ext/mysqli) and so the bug can happen with
mysql_init()/mysqli_real_connect() and mysql_connect('p:', ...).
Therefore we test both cases. Note the (tricky?) difference between the
implementation detail'mysqlnd private persistent flag = use malloc()'
and persistent connections from a user perspective. Although mysqlnd
will always set its private persistent flag and  use malloc() for
connections created with mysqli_init() it is still up to the user to
decide in mysqli_real_connect() if the connection shall become a (true)
persistent connection or not.



[2009-09-02 13:27:42] vr...@php.net

CREATE TABLE and sample CSV included in
http://www.vrana.cz/phpbug49442.zip



[2009-09-02 13:21:23] paj...@php.net

Please provide the create table and a small CSV to reproduce the
problem.



[2009-09-02 12:46:06] vr...@php.net

Backtrace analysis is available at http://www.vrana.cz/phpbug49442.zip



[2009-09-02 12:32:21] vr...@php.net

Description:

LOAD DATA LOCAL INFILE query together with connecting by
mysqli_real_connect() causes PHP crash. Maybe it is not the single
crashing query but common queries like SELECT or INSERT work.

When I replace mysqli_init() + mysqli_real_connect() by
mysqli_connect() then everything works (no crash).

Reproduce code:
---
real_connect("", "ODBC", "", "cds");
$dbh->query("LOAD DATA LOCAL INFILE 'songs.csv' INTO TABLE songs");
?>


Expected result:

Query executed OK.

Actual result:
--
PHP crashes.





-- 
Edit this bug report at http://bugs.php.net/?id=49442&edit=1

#49573 [Opn]: Mysqli_info doesn't return results when using INSERT .. values

[uw]

 ID:   49573
 Updated by:   u...@php.net
 Reported By:  terryllong at gmail dot com
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Windows XP
 PHP Version:  5.3.0
 New Comment:

It could be a bogus bug because: "Note that mysql_info() returns a
non-NULL value for INSERT ... VALUES only for the multiple-row form of
the statement (that is, only if multiple value lists are specified)",
http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html 

Please check what happens for the statements listed in the MySQL
manual.



Previous Comments:


[2009-09-16 21:12:30] terryllong at gmail dot com

Description:

Mysqli_info doesn't seem to return results 
when using INSERT .. values

Reproduce code:
---



Expected result:

Expect text string show the results of the insert.


Actual result:
--
Results of Insert query returns a string(0) as shown with a Var_dump





-- 
Edit this bug report at http://bugs.php.net/?id=49573&edit=1

#49573 [Opn->Bgs]: Mysqli_info doesn't return results when using INSERT .. values

[uw]

 ID:   49573
 Updated by:   u...@php.net
 Reported By:  terryllong at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: Windows XP
 PHP Version:  5.3.0
 New Comment:

I checked the tests. They cover all supported statements and they pass.


If you want mysqli_info() to support more than the statements listed in
the MySQL documentation, please file a feature request at
bugs.mysql.com.


Previous Comments:


[2009-09-16 23:15:59] u...@php.net

It could be a bogus bug because: "Note that mysql_info() returns a
non-NULL value for INSERT ... VALUES only for the multiple-row form of
the statement (that is, only if multiple value lists are specified)",
http://dev.mysql.com/doc/refman/5.1/en/mysql-info.html 

Please check what happens for the statements listed in the MySQL
manual.




[2009-09-16 21:12:30] terryllong at gmail dot com

Description:

Mysqli_info doesn't seem to return results 
when using INSERT .. values

Reproduce code:
---



Expected result:

Expect text string show the results of the insert.


Actual result:
--
Results of Insert query returns a string(0) as shown with a Var_dump





-- 
Edit this bug report at http://bugs.php.net/?id=49573&edit=1

#47629 [Opn]: mysqli connect timeout causes fatal error

[uw]

 ID:   47629
 Updated by:   u...@php.net
 Reported By:  danielc at analysisandsolutions dot com
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Windows XP SP3
 PHP Version:  5.3CVS-2009-03-12 (snap)
 New Comment:

I don't see a bug here either.

The windows binaries from php.net default to mysqlnd as of PHP 5.3. The
PHP 5.2 ones should use the MySQL Client Library. The MySQL Client
Library uses its own network layer abstraction whereas mysqlnd uses PHP
streams. 

The default CONNECT_TIMEOUT of mysqlnd is 0, unless overruled by API
settings (mysql.connect_timeout,  MYSQLI_OPT_CONNECT_TIMEOUT,
, ...). The MySQL Client Library
uses the same default. Both PHP streams and the MySQL Client Library
pass the value down to the network functions. 

Regarding READ_TIMEOUT please see http://bugs.php.net/bug.php?id=49511
. 

Seems that your main point is about the Fatal error. In my eyes this is
what shall happen - no bug:

"Note: The set_time_limit() function and the configuration directive
max_execution_time  only affect the execution time of the script itself.
Any time spent on activity that happens outside the execution of the
script such as system calls using system(), stream operations, database
queries, etc. is not included when determining the maximum time that the
script has been running. This is not true on Windows where the measured
time is real.", http://de3.php.net/set_time_limit

According to the documentation the time limit on Windows is real time.
That is wall clock. The script should stop after max_execution_time -
default_socket_timeout > max_execution_time does not matter.

The question is if/why the timeout does not happen (on PHP 5.2, 5.3?)
when using the MySQL Client Library on Windows. The way I read the
manual time spend on database operations should be taken into account on
Windows. 

And that is a matter of the PHP time limit functionality (-> Category:
General/similar not MySQLi related)


Previous Comments:


[2009-06-22 15:58:32] danielc at analysisandsolutions dot com

I'll put together tests of the various functions and report back.



[2009-06-21 09:04:11] paj...@php.net

"1) That's how PHP 5.2 does it."

Not really relevant in this case.

"2) That's how the other socket functions do it in 5.2 and 5.3."

Then there is a bug here.

"3) The timeout is from communication with another entity, not from
the
script itself."

The max_execution_time has the highest priority and should always has
it. If it is not the case in one function or another then there is a bug
in this function.



[2009-06-21 00:48:41] danielc at analysisandsolutions dot com

Because:
1) That's how PHP 5.2 does it.
2) That's how the other socket functions do it in 5.2 and 5.3.
3) The timeout is from communication with another entity, not from the
script itself.



[2009-06-20 20:12:24] paj...@php.net

but there is no bug here. Why do you want to let the socket timeout
override the main timeout?



[2009-06-20 17:34:32] dani...@php.net

Yes, the execution timeout makes sense some ways.  The problem is the
behavior is inconsistent between 5.2 and 5.3 and between other
connection functions.



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/47629

-- 
Edit this bug report at http://bugs.php.net/?id=47629&edit=1

#49562 [Fbk->Bgs]: mysql_info() hides warnings for single-row INSERT's

[uw]

 ID:   49562
 Updated by:   u...@php.net
 Reported By:  jille at hexon dot cx
-Status:   Feedback
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  5.3.0
 New Comment:

Please see http://bugs.php.net/bug.php?id=49573 for an explanation.

mysql_info() does not return anything for single-row INSERTs and that
is how it should be.


Previous Comments:


[2009-09-16 07:34:50] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-09-15 13:08:24] jille at hexon dot cx

Description:

mysql_info() returns false when inserting only one row. This results in
the unability to retreive the number of warnings which might have
occurred.

if $numWarnings > 0 I would like to retreive the warnings with
mysql_query("SHOW WARNINGS"); but I'd prefer not doing that if there are
no warnings.

Reproduce code:
---
mysql_query("CREATE TABLE a (a VARCHAR(4))");
mysql_query("INSERT INTO a (a) VALUES ('abcde')");
var_dump(mysql_info());

Expected result:

Just like the mysql-CLI:

mysql> INSERT INTO a (a) VALUES ('abcde');
Query OK, 1 row affected, 1 warning (0.01 sec)

so something like "1 row affected, 1 warning" would be perfect

Actual result:
--
bool(false)






-- 
Edit this bug report at http://bugs.php.net/?id=49562&edit=1

#48909 [Opn->Fbk]: Segmentation fault in mysqli_stmt_execute

[uw]

 ID:   48909
 Updated by:   u...@php.net
 Reported By:  etremblay at kronostechnologies dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Kubuntu hardy
 PHP Version:  5.3CVS-2009-07-13 (snap)
 New Comment:

Good too hear that it does not happen with mysqlnd. 

It is hard to comment without a reproducible test case. 

If you cannot isolate the issue, maybe you can check if the problem
exists with the latest version of the MySQL Client Library and maybe you
can even use a debug version?

Thanks


Previous Comments:


[2009-07-13 21:43:40] etremblay at kronostechnologies dot com

I'have compiled php with mysqlnd (--with-mysqli=mysqlnd) and the
problem is solved.

Note that with earlyer version of php, 5.2.9, there was no problem with
libmysql and the same query.



[2009-07-13 20:40:28] etremblay at kronostechnologies dot com

Description:

I'have not yet isolated the problem, but since updating to 5.3.0
(snapshot), some prepared statement cause segmentation fault.

Reproduce code:
---
NOTE : Fields 0 to 4 are php serialized objects.

$update_stmt->bind_param('bs', $bidon, $bidon, $bidon, $bidon,
$bidon,$system_name);
$update_stmt->send_long_data(0,
$serializedFieldRef);   
$update_stmt->send_long_data(1,
$serializedFieldRef2);  
$update_stmt->send_long_data(2,
$serializedFieldRef3);  
$update_stmt->send_long_data(3,
$serializedFieldRef4);  
$update_stmt->send_long_data(4,
$serializedSelection);  $update_stmt->execute();

Expected result:

The query is executed

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb74589f0 (LWP 16404)]
0x0828a9f7 in php_mysqli_stmt_copy_it (copies=0xbfeb9540, original=0x0,
param_count=6, current=0) at
/opt/php5.3-200907131830/ext/mysqli/mysqli_api.c:706
706 *(*copies)[current] = *original;
(gdb) bt
#0  0x0828a9f7 in php_mysqli_stmt_copy_it (copies=0xbfeb9540,
original=0x0, param_count=6, current=0) at
/opt/php5.3-200907131830/ext/mysqli/mysqli_api.c:706
#1  0x0828abb4 in zif_mysqli_stmt_execute (ht=0,
return_value=0xce3fd30, return_value_ptr=0x0, this_ptr=0xce3ca90,
return_value_used=0) at
/opt/php5.3-200907131830/ext/mysqli/mysqli_api.c:736
#2  0x084d1a4a in zend_do_fcall_common_helper_SPEC
(execute_data=0xa266414) at
/opt/php5.3-200907131830/Zend/zend_vm_execute.h:313
#3  0x084d2650 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xa266414) at
/opt/php5.3-200907131830/Zend/zend_vm_execute.h:422
#4  0x084d0eba in execute (op_array=0xa24f678) at
/opt/php5.3-200907131830/Zend/zend_vm_execute.h:104
#5  0x084a6520 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /opt/php5.3-200907131830/Zend/zend.c:1188
#6  0x0843c30f in php_execute_script (primary_file=0xbfebb9c4) at
/opt/php5.3-200907131830/main/main.c:2212
#7  0x085668d5 in main (argc=7, argv=0xbfebbb34) at
/opt/php5.3-200907131830/sapi/cli/php_cli.c:1188





-- 
Edit this bug report at http://bugs.php.net/?id=48909&edit=1

#48909 [Opn->Fbk]: Segmentation fault in mysqli_stmt_execute

[uw]

 ID:   48909
 Updated by:   u...@php.net
 Reported By:  etremblay at kronostechnologies dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Kubuntu jaunty
 PHP Version:  PHP 5.3.2-dev (cli) (built: Sep 17 2009 08:48:06)
 New Comment:

Problem remains: we need a reproducible test case. So, please try to
isolate a test. 

Also, using snapshot may not matter. It may be a matter of the MySQL
Client Library. Make sure that you use the latest version of the MySQL
Client library when compiling PHP.

Thanks!


Previous Comments:


[2009-09-17 13:06:07] etremblay at kronostechnologies dot com

I just retryed with today php snapshot (php5.3-200909171030)

With  --with-mysql --with-mysqli
MysqlI Support => enabled
Client API library version => 5.0.75
Active Persistent Links => 0
Inactive Persistent Links => 0  
Active Links => 0   
Client API header version => 5.0.75 
MYSQLI_SOCKET => /var/run/mysqld/mysqld.sock

I still got the segementation fault.

With --with-mysql=mysqlnd --with-mysql=mysqlnd
The same query work fine.

I'm affraid I haven't mutch more time to spend on it.



[2009-09-17 11:53:22] u...@php.net

Good too hear that it does not happen with mysqlnd. 

It is hard to comment without a reproducible test case. 

If you cannot isolate the issue, maybe you can check if the problem
exists with the latest version of the MySQL Client Library and maybe you
can even use a debug version?

Thanks



[2009-07-13 21:43:40] etremblay at kronostechnologies dot com

I'have compiled php with mysqlnd (--with-mysqli=mysqlnd) and the
problem is solved.

Note that with earlyer version of php, 5.2.9, there was no problem with
libmysql and the same query.



[2009-07-13 20:40:28] etremblay at kronostechnologies dot com

Description:

I'have not yet isolated the problem, but since updating to 5.3.0
(snapshot), some prepared statement cause segmentation fault.

Reproduce code:
---
NOTE : Fields 0 to 4 are php serialized objects.

$update_stmt->bind_param('bs', $bidon, $bidon, $bidon, $bidon,
$bidon,$system_name);
$update_stmt->send_long_data(0,
$serializedFieldRef);   
$update_stmt->send_long_data(1,
$serializedFieldRef2);  
$update_stmt->send_long_data(2,
$serializedFieldRef3);  
$update_stmt->send_long_data(3,
$serializedFieldRef4);  
$update_stmt->send_long_data(4,
$serializedSelection);  $update_stmt->execute();

Expected result:

The query is executed

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb74589f0 (LWP 16404)]
0x0828a9f7 in php_mysqli_stmt_copy_it (copies=0xbfeb9540, original=0x0,
param_count=6, current=0) at
/opt/php5.3-200907131830/ext/mysqli/mysqli_api.c:706
706 *(*copies)[current] = *original;
(gdb) bt
#0  0x0828a9f7 in php_mysqli_stmt_copy_it (copies=0xbfeb9540,
original=0x0, param_count=6, current=0) at
/opt/php5.3-200907131830/ext/mysqli/mysqli_api.c:706
#1  0x0828abb4 in zif_mysqli_stmt_execute (ht=0,
return_value=0xce3fd30, return_value_ptr=0x0, this_ptr=0xce3ca90,
return_value_used=0) at
/opt/php5.3-200907131830/ext/mysqli/mysqli_api.c:736
#2  0x084d1a4a in zend_do_fcall_common_helper_SPEC
(execute_data=0xa266414) at
/opt/php5.3-200907131830/Zend/zend_vm_execute.h:313
#3  0x084d2650 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xa266414) at
/opt/php5.3-200907131830/Zend/zend_vm_execute.h:422
#4  0x084d0eba in execute (op_array=0xa24f678) at
/opt/php5.3-200907131830/Zend/zend_vm_execute.h:104
#5  0x084a6520 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /opt/php5.3-200907131830/Zend/zend.c:1188
#6  0x0843c30f in php_execute_script (primary_file=0xbfebb9c4) at
/opt/php5.3-200907131830/main/main.c:2212
#7  0x085668d5 in main (argc=7, argv=0xbfebbb34) at
/opt/php5.3-200907131830/sapi/cli/php_cli.c:1188





-- 
Edit this bug report at http://bugs.php.net/?id=48909&edit=1

#46144 [Opn]: failed prepare() does not fill error and errno fields

[uw]

 ID:   46144
 Updated by:   u...@php.net
 Reported By:  Progman2002 at gmx dot de
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-01-25 (snap)
 New Comment:

I don't know what to do with this report because in a way it is a user
error. The problem can easily be avoided by calling the destructor of
the mysql_statement class before assigning false to it. A simple
$stmt->close() before the second $stmt = $db->prepare() will fix it.


What happens is:

 $stmt = ... 
 $stmt = $mysqli->prepare('wrong_sql');

 
  

C API: mysql_stmt_init()
C API: mysql_stmt_prepare() -> error
copy error, because mysql_stmt_close() will clean it
C API: mysql_stmt_close()

RETURN false

 

 
$stmt is a Prepared Statement for 
destruct $stmt, because user did not clean it up!

C API: mysql_stmt_close() 
!!! previously saved error message gets cleaned !!!

 

 
 

 var_dump($mysqli->error) -> no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct
and copy the error message into some safe place. But I wonder how we
would know when to return the message copied into a safe place and when
not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd
behave different to libmysql (not clean/preserve error message in
mysqlnd' stmt dtor) but that would be just the wrong place and really
hackish

Maybe we should set the status to "Won't fix".


Previous Comments:


[2009-05-18 14:43:14] Progman2002 at gmx dot de

Sure I can call close() by myself (which I normally do), but it doesn't
solve the bug itself. The point is you get an error situation and don't
know why.



[2009-05-18 02:17:56] felix9x at yahoo dot com

It's because the first $stmt object is destroyed by the second
assignment (which clears the last error message).

$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db->prepare($sql)) {
die($db->error."-".$db->errno."-".$db->info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt->close() explicitly. Probably best to use
this syntax:

$sql = 'INSERT INTO
t(i)
WHERE
(?)';
$stmt = $db->stmt_init();
if(!$stmt->prepare($sql) ){
  die( $stmt->error );
}



[2009-01-25 10:50:41] Progman2002 at gmx dot de

The bug is still not fixed. Maybe it has something to do with an
uncalled destructor since I use the same variable $stmt.

Actual result:
--
PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
-0-

Expected result:

PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
(Showing a MySQL error which says "Syntax error near WHERE (?,?)" or
says sth. like "unfinished prepare statement before")



[2008-11-29 10:59:24] Progman2002 at gmx dot de

As the paste on the pasteboard is gone I'll add the code here.
---

server_version."\n";
echo 'MySQL-Protocol: '.$db->protocol_version."\n";
$sql = 'CREATE TEMPORARY TABLE SomeTest(UserID INT NOT NULL, RechtID
INT NOT NULL)';
if (!$db->query($sql)) {
die($db->error);
}
$sql = 'DELETE FROM
SomeTest
WHERE
UserID = ?';
if (!$stmt = $db->prepare($sql)) {
die($db->error);
}
// note the missing $stmt->close() here
$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db->prepare($sql)) {
die($db->error."-".$db->errno."-".$db->info);
}
echo "done";
?>



[2008-09-21 13:49:28] Progman2002 at gmx dot de

Description:

If you create a prepared statement with a DELETE query and tries to
create a second prepared statement with an INSERT query on the same
table without closing the first one the MySQLi::prepare() method failed,
but the fields $error and $errno (and all other related to them) aren't
filled with the error message. This is strange as the prepare() failed
but you dont know why.

The mysql error is shown if I save the second statement into another
variable (like if (!$stmt2 = $db->prepare($sql))) (maybe its related to
bug #44766)

Reproduce code:
---
Code is at http://nopaste.php-quake.net/51976

Expected result:

PHP-Version: 5.2.6-pl7-gentoo
MySQL-Server-Version: 50042
MySQL-Protocol: 10
{Showing a MySQL error which says "Syntax error near WHERE (?,?)" or
says sth. like "unfinished prepare statement before")

Actual result:
--
PHP-Vers

#46144 [Opn]: failed prepare() does not fill error and errno fields

[uw]

 ID:   46144
 Updated by:   u...@php.net
 Reported By:  Progman2002 at gmx dot de
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-01-25 (snap)
 New Comment:

After spending the evening on it, I am even more in the mood to change
status to "Won't fix".

Even if we copy error messages to a safe place we need to know when to
return the prepare error message. We should return the prepare error
message, if any mysql C API call made between the failed prepare and the
fetch of the error message by the user have succeeded. "Any" refers to
all calls made implicitly by the destructor of the overwritten statement
object before mysqli->prepare() returns. "Any" must not include calls
made by the user after prepare(). Something simple will not work:

mysql_error():

  if (prepare_error && no_regular_error)
clean_and_return_pepare_error;

That simple approach would not ensure that "any" is as small as we want
it to be. We would need another flag that tells us if the user has made
any API calls after prepare() and before fetchting the error().

And that gets you into a real mess: intercept all PHP API calls? Maybe
abuse mysql->mysql->net.errno (a private member) again to check if it
gets reset - every C API call resets it. If our special
"prepare_error_fetch" flag is gone, the user must have made an API call
after prepare. Oh, problem, no mysql->mysql struct available in the
statement destructor that calls mysql_stmt_close()... what about
introducing a new global structure for tracking to be able to link
statements and connections, *ouch* -> "Won't fix"...


Previous Comments:


[2009-09-17 17:41:48] u...@php.net

I don't know what to do with this report because in a way it is a user
error. The problem can easily be avoided by calling the destructor of
the mysql_statement class before assigning false to it. A simple
$stmt->close() before the second $stmt = $db->prepare() will fix it.


What happens is:

 $stmt = ... 
 $stmt = $mysqli->prepare('wrong_sql');

 
  

C API: mysql_stmt_init()
C API: mysql_stmt_prepare() -> error
copy error, because mysql_stmt_close() will clean it
C API: mysql_stmt_close()

RETURN false

 

 
$stmt is a Prepared Statement for 
destruct $stmt, because user did not clean it up!

C API: mysql_stmt_close() 
!!! previously saved error message gets cleaned !!!

 

 
 

 var_dump($mysqli->error) -> no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct
and copy the error message into some safe place. But I wonder how we
would know when to return the message copied into a safe place and when
not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd
behave different to libmysql (not clean/preserve error message in
mysqlnd' stmt dtor) but that would be just the wrong place and really
hackish

Maybe we should set the status to "Won't fix".



[2009-05-18 14:43:14] Progman2002 at gmx dot de

Sure I can call close() by myself (which I normally do), but it doesn't
solve the bug itself. The point is you get an error situation and don't
know why.



[2009-05-18 02:17:56] felix9x at yahoo dot com

It's because the first $stmt object is destroyed by the second
assignment (which clears the last error message).

$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db->prepare($sql)) {
die($db->error."-".$db->errno."-".$db->info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt->close() explicitly. Probably best to use
this syntax:

$sql = 'INSERT INTO
t(i)
WHERE
(?)';
$stmt = $db->stmt_init();
if(!$stmt->prepare($sql) ){
  die( $stmt->error );
}



[2009-01-25 10:50:41] Progman2002 at gmx dot de

The bug is still not fixed. Maybe it has something to do with an
uncalled destructor since I use the same variable $stmt.

Actual result:
--
PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
-0-

Expected result:

PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
(Showing a MySQL error which says "Syntax error near WHERE (?,?)" or
says sth. like "unfinished prepare statement before")



[2008-11-29 10:59:24] Progman2002 at gmx dot de

As the paste on the pasteboard is gone I'll add the code here.
---

server_version."\n";
echo 'MySQL-Protocol: '.$db->protocol_version."\n";
$sql = 'CREATE

#49381 [Opn]: PDO mysql prepare incorrectly quoting

[uw]

 ID:   49381
 Updated by:   u...@php.net
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

It is not a MySQL bug. MySQL native prepared statements to not support
using bind variables as identifiers.

http://dev.mysql.com/doc/refman/5.1/en/prepare.html

At most it is a bug of the PDO prepared statement emulation parser. 



Previous Comments:


[2009-08-27 03:35:02] eprayner at gmail dot com

MYSQL Server version: 5.0.67-0ubuntu6 (Ubuntu)

>From reading other bugs, I'm beginning to think this is a MySQL bug,
rather than a PHP bug.



[2009-08-27 03:31:03] eprayner at gmail dot com

Description:

When using PDO prepare for mysql, quotes are incorrectly inserted
around column names, resulting in errors or unexpected results.  This
problem would have been _much_ easier to diagonise if there was a way of
seeing the actual statement.  Something like:
$string PDOStatement::executeString()---returns the statement that
would have been executed by PDOStatement::execute().

Reproduce code:
---
//given a mysql connection $pdo
//and a database table 'myTable' with columns: id, col1, col2, col3
//with a row: 1, value1, value2, value3.

$stmt=$pdo->prepare("SELECT ? FROM myTable WHERE id=?");
$myColumn = 'col1';
$stmt->execute(array($myColumn, 1));
$row=$stmt->fetch();
print_r($row);

Expected result:

I'd expect to see: "value1" displayed, as you'd expect for the
statement: "SELECT col1 FROM myTable WHERE id=1"

Actual result:
--
What is displayed is: "col1", as you'd expect for the statement:
"SELECT 'col1' FROM myTable WHERE id=1"

Other statements result in errors.  Example:
$stmt=$pdo->prepare("UPDATE myTable SET ?=? WHERE id=?");
$stmt->execute(array($myColumn, $myValue, $myId));

is a syntax error, as is the SQL:
UPDATE myTable SET 'col1'=3 WHERE id=1;

This problem means that I cant use prepare and execute statements at
all.





-- 
Edit this bug report at http://bugs.php.net/?id=49381&edit=1

#49308 [Asn]: random crashes on freeing mysqli result storage

[uw]

 ID:   49308
 Updated by:   u...@php.net
 Reported By:  f4ckm5 at web dot de
 Status:   Assigned
 Bug Type: MySQLi related
 Operating System: Windows Server 2003 SP2 32Bit
 PHP Version:  5.3, 6 (2009-08-22)
 Assigned To:  mysql
 New Comment:

Well, do you have any tips in what to do with the trace? Sorry, but a
reproducible case would be much more worth than the trace.

Alternatively, is it possible to enable the mysqlnd trace?


Previous Comments:


[2009-08-29 15:31:34] f4ckm5 at web dot de

Do you have any tips on how to find the respective lines of code in a
7 lines of code project which eventually cause the crash? All i can
see is the dying apache worker thread and the corresponding message in
the system log. And it is very annoying, that this happens only on the
productive system. No crashes on our development and test machines.
I would gladly provide a test script. Just tell me where to start
digging.



[2009-08-26 15:38:34] u...@php.net

Any chance to provide a test script? I know its hard, but its also hard
to say anything based on the backtrace and without a reproducible test
case.

Thanks,
Ulf



[2009-08-21 09:31:38] f4ckm5 at web dot de

I used the latest Snapshot 5.3.1-dev from Thu Aug 20 15:19:10 2009

The crashes became less frequent. Instead of 10 in 5 Minutes i caught
only 5 in 3.5 hours. But the crashes still occur:

#

Thread 250 - System ID 9828
Entry point   msvcrt!_endthreadex+2f 
Create time   21.08.2009 09:11:23 
Time spent in user mode   0 Days 0:0:0.171 
Time spent in kernel mode   0 Days 0:0:0.78 


Function Arg 1 Arg 2 Arg 3   Source 
php5ts!_zend_mm_free_int+139 056cf838 00050004 00720336   

php5ts!_efree+36 012296e8 06894910 00725877
php5ts!_zval_ptr_dtor+66 068948e4 006ad310 06868980
php5ts!zend_hash_destroy+27 06876538 06868980 015a1665
php5ts!zend_object_std_dtor+2b 06868980 056ce490 06868980  
 
php_mysqli!mysqli_objects_free_storage+25 06868980 056ce490
05a733e4
php_mysqli!mysqli_result_free_storage+28 06868980 056ce490
056ce490
php5ts!zend_objects_store_del_ref_by_handle_ex+1b6 002b
015b1600 056ce490
php5ts!zend_objects_store_del_ref+1e 06868960 056ce490

php5ts!_zval_dtor_func+76 06868960  05ab9050
php5ts!ZEND_ASSIGN_SPEC_CV_VAR_HANDLER+237 0546fbfc 056ce490   
 0546fe78
php5ts!execute+29e 05ab9050 056ce400 
php5ts!zend_execute_scripts+f6 0008 056ce490   
 
php5ts!php_execute_script+22d 0546fe78 056ce490 0003   

php5apache2_2!php_handler+5d0 012c18b8 00615988 012c18b8   

libhttpd!ap_run_handler+21 012c18b8 012c18b8 012c18b8
libhttpd!ap_invoke_handler+ae  012bc860 0546ff3c   

libhttpd!ap_die+29e 012c18b8  0065fb90
libhttpd!ap_get_request_note+1ccc 012bc860 012bc860
012bc860
libhttpd!ap_run_process_connection+21 012bc860 0062b108
0546ff84
libhttpd!ap_process_connection+33 012bc860 012b1820

libhttpd!ap_regkey_value_remove+c7c 012bc858 

msvcrt!_endthreadex+a3 012a7d08  
kernel32!BaseThreadStart+34 77b9b4bc 012a7d08 


PHP5TS!_ZEND_MM_FREE_INT+139In
httpd__PID__7192__Date__08_21_2009__Time_09_11_24AM__898__First chance
exception 0XC005.dmp the assembly instruction at
php5ts!_zend_mm_free_int+139 in C:\PHP\php5ts.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x02080174 on thread 250

Module Information 
Image Name: C:\PHP\php5ts.dll
Symbol Type:  PDB 
Base address: 0x006a
Time Stamp:  Thu Aug 20 15:19:10 2009  
Checksum: 0x
Comments:   
COM DLL: False
Company Name:  The PHP Group 
ISAPIExtension: False
File Description:  PHP Script Interpreter 
ISAPIFilter: False
File Version:  5.3.1-dev 
Managed DLL: False
Internal Name:  PHP Script Interpreter 
VB DLL: False
Legal Copyright:  Copyright © 1997-2009 The PHP Group 
Loaded Image Name:  php5ts.dll
Legal Trademarks:  PHP 
Mapped Image Name:  C:\PHP\php5ts.dll
Original filename:  php5ts.dll 
Module name:  php5ts
Private Build:   
Single Threaded:  False
Product Name:  PHP 
Module Size:  5,45 MBytes
Product Version:  5.3.1-dev 
Symbol File Name:  C:\Dokumente und
Einstellungen\Administrator.HML\Desktop\php-debug-pack-5.3-win32-VC6-x86-latest\php5ts.pdb
Special Build:  &



[2009-08-

#49262 [Opn]: PDO MySQL doesn't take STRING params

[uw]

 ID:   49262
 Updated by:   u...@php.net
 Reported By:  grzegorz at heex dot pl
 Status:   Open
 Bug Type: PDO related
 Operating System: Win XP Sp3
 PHP Version:  5.3.0
 New Comment:

Can you say anything about the character sets you are using?


Previous Comments:


[2009-08-25 07:57:54] grzegorz at heex dot pl

FunctionArg 1   Arg 2   Arg 3 Source
php5ts!mysqlnd_cset_escape_slashes+30   05652000   
0565fb58  
php_pdo_mysql!_pdo_mysql_error+6f7  0565f5880565fb58   
0006  
php5ts!pdo_parse_params+394 05662d5005662e780026
  
php5ts!pdo_stmt_describe_columns+7720565f638   
  
php5ts!execute+10b9 05690070015e5801007f66b8  
php5ts!execute+156d 015e585803e8fbe0  
php5ts!execute+298  0565dbf0015e5800015e5858  
php5ts!zend_execute_scripts+fe  0008015e5858
 

php5ts!php_execute_script+231   03e8fe6c015e58580005
 

php5apache2_2!zm_info_apache+1744   007aa7600073a400   
007aa760  
libhttpd!ap_run_handler+21  007aa760007aa760007aa760
  
libhttpd!ap_invoke_handler+ae   007a771803e8ff38
 

libhttpd!ap_die+24e 007aa7600073aac8  
libhttpd!ap_get_request_note+1c6c   007a7718007a7718   
007a7718  
libhttpd!ap_run_process_connection+21   007a77180074a198   
03e8ff80  
libhttpd!ap_process_connection+33   007a7718007a26d8   
0006fb80  
libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80   
00eb0650  
msvcrt!_endthreadex+a9  0079ef880006fb8000eb0650  
kernel32!BaseThreadStart+37 77c2a3410079ef88
  



PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In
httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in
C:\php5\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x0010 on thread 157



[2009-08-24 19:55:42] sjo...@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.





[2009-08-14 20:23:43] grzegorz at heex dot pl

Description:

Now, PDO in PHP 5.3 is usless.

Reproduce code:
---
$name = 'same_name';
$pdo= new
PDO("mysql:host=localhost;dbname=[base];",'[user]','[pass]');
$sth = $pdo->prepare("SELECT * FROM lng WHERE lng_name=:Name");
$sth->bindValue(':Name',$name,PDO::PARAM_STR);
$sth->execute();
die('OK');

Expected result:

OK

Actual result:
--
PHP CGI / FastCGI crash





-- 
Edit this bug report at http://bugs.php.net/?id=49262&edit=1

#49258 [Opn->Csd]: PDO MySQL execute(array) causes CGI/FastCGI crash

[uw]

 ID:   49258
 Updated by:   u...@php.net
 Reported By:  grzegorz at heex dot pl
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Win XP Sp3
 PHP Version:  5.3.0
 New Comment:

Closing in favour of http://bugs.php.net/bug.php?id=49262 . 

This one is a duplicate because: PDO emulation used, no type specified
= default to type string = #49262 scenario.


Previous Comments:


[2009-08-14 17:40:34] grzegorz at heex dot pl

Description:

PHP crashes if there is no PDO_Type of param

Reproduce code:
---
$pdo = new
PDO("mysql:host=localhost;dbname=[base];",'[user]','[pass]');

$sth = $pdo->prepare("SELECT * FROM lng WHERE lng_id=:Id");
$id = 1;

//causes PHP crash
$sth->execute(array(':Id'=>$id));
//OR
//$sth->bindParam(':Id',$id);$sth->execute();

//works fine:
//$sth->bindValue(':Id',$id,PDO::PARAM_INT);
//$sth->execute();

die('OK');

Expected result:

OK

Actual result:
--
PHP CGI/FastCGI crash





-- 
Edit this bug report at http://bugs.php.net/?id=49258&edit=1

#46144 [Opn]: failed prepare() does not fill error and errno fields

[uw]

 ID:   46144
 Updated by:   u...@php.net
 Reported By:  Progman2002 at gmx dot de
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-01-25 (snap)
 New Comment:

Simple: there aint no two statement objects. You got one statement
object and one statement struct from the first successful statement. The
second struct is destroyed before prepare() returns. 

The error messages is communicated to mysql_error using the connection
object, the mysql struct.


Previous Comments:


[2009-09-18 10:14:09] Progman2002 at gmx dot de

Aren't the prepared statement saved in different MYSQL_STMT structs? If
so why do one mysql_stmt_close() in one struct clear the last_error
field in the other one? Or is the destructor called too late (on the new
created statement), after the (php-)objects are
relocated/replaced/reassigned?



[2009-09-18 07:49:26] u...@php.net

After spending the evening on it, I am even more in the mood to change
status to "Won't fix".

Even if we copy error messages to a safe place we need to know when to
return the prepare error message. We should return the prepare error
message, if any mysql C API call made between the failed prepare and the
fetch of the error message by the user have succeeded. "Any" refers to
all calls made implicitly by the destructor of the overwritten statement
object before mysqli->prepare() returns. "Any" must not include calls
made by the user after prepare(). Something simple will not work:

mysql_error():

  if (prepare_error && no_regular_error)
clean_and_return_pepare_error;

That simple approach would not ensure that "any" is as small as we want
it to be. We would need another flag that tells us if the user has made
any API calls after prepare() and before fetchting the error().

And that gets you into a real mess: intercept all PHP API calls? Maybe
abuse mysql->mysql->net.errno (a private member) again to check if it
gets reset - every C API call resets it. If our special
"prepare_error_fetch" flag is gone, the user must have made an API call
after prepare. Oh, problem, no mysql->mysql struct available in the
statement destructor that calls mysql_stmt_close()... what about
introducing a new global structure for tracking to be able to link
statements and connections, *ouch* -> "Won't fix"...



[2009-09-17 17:41:48] u...@php.net

I don't know what to do with this report because in a way it is a user
error. The problem can easily be avoided by calling the destructor of
the mysql_statement class before assigning false to it. A simple
$stmt->close() before the second $stmt = $db->prepare() will fix it.


What happens is:

 $stmt = ... 
 $stmt = $mysqli->prepare('wrong_sql');

 
  

C API: mysql_stmt_init()
C API: mysql_stmt_prepare() -> error
copy error, because mysql_stmt_close() will clean it
C API: mysql_stmt_close()

RETURN false

 

 
$stmt is a Prepared Statement for 
destruct $stmt, because user did not clean it up!

C API: mysql_stmt_close() 
!!! previously saved error message gets cleaned !!!

 

 
 

 var_dump($mysqli->error) -> no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct
and copy the error message into some safe place. But I wonder how we
would know when to return the message copied into a safe place and when
not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd
behave different to libmysql (not clean/preserve error message in
mysqlnd' stmt dtor) but that would be just the wrong place and really
hackish

Maybe we should set the status to "Won't fix".



[2009-05-18 14:43:14] Progman2002 at gmx dot de

Sure I can call close() by myself (which I normally do), but it doesn't
solve the bug itself. The point is you get an error situation and don't
know why.



[2009-05-18 02:17:56] felix9x at yahoo dot com

It's because the first $stmt object is destroyed by the second
assignment (which clears the last error message).

$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db->prepare($sql)) {
die($db->error."-".$db->errno."-".$db->info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt->close() explicitly. Probably best to use
this syntax:

$sql = 'INSERT INTO
t(i)
WHERE
(?)';
$stmt = $db->stmt_init();
if(!$stmt->prepare($sql) ){
  die( $stmt->error );
}

--

#49381 [Opn]: PDO mysql prepare incorrectly quoting

[uw]

 ID:   49381
 Updated by:   u...@php.net
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

PDO is an API abstraction layer. It neither does abstract SQL
differences nor does PDO pay much attention to provide a unified type
system. Users need to pay attention to differences between SQL dialects
on their own.

I understand that it would be helpful to have summary on SQL
differences somewhere but on the other hand I would understand the
documentation team to just link to any such document but keep details
itself out of the core documentation. Just my thoughts...

I am not sure what you mean by "efficiency payoff". A client side
emulation of PS has different properties than server side PS. IMHO there
is no clear line on what is preferrable. 

The PDO SQL parser is provided by the PDO core. This is a tricky design
decision because it is one SQL parser for all the different SQL
dialects. The PDO SQL parser is very generic and you can find edge cases
in the bug system where it fails. 

Even if the client side emulation may give you a feature you want, you
should be aware of the overall design and not forget about its
limitations.

What happens in this case is that PDO parses your statement, recognizes
a placeholder and tries to replace it with the bound value. To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen. 

Two solutions come to my mind: either you allow users to hint PDO that
nothing shall be escaped or you take the safe but stony road of
improving the PDO parser and teach it (for all SQL dialects!) what an
identifier is. Both solutions would require changing the core of PDO.


Previous Comments:


[2009-09-18 10:46:45] eprayner at gmail dot com

OK.  At http://dev.mysql.com/doc/refman/5.1/en/prepare.html
it says 'Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.'
So either this is a restriction for php PDOs, in which case it should
be explained in the documentation, or it is a problem with php's 'PDO
prepared statement emulation parser', as you say.
It is nice to know, at least, that even if php PDOs were 'improved' to
handle 'column parameter markers', there would be no efficiency payoff
(with mysql at least).



[2009-09-18 08:19:53] u...@php.net

It is not a MySQL bug. MySQL native prepared statements to not support
using bind variables as identifiers.

http://dev.mysql.com/doc/refman/5.1/en/prepare.html

At most it is a bug of the PDO prepared statement emulation parser. 




[2009-08-27 03:35:02] eprayner at gmail dot com

MYSQL Server version: 5.0.67-0ubuntu6 (Ubuntu)

>From reading other bugs, I'm beginning to think this is a MySQL bug,
rather than a PHP bug.



[2009-08-27 03:31:03] eprayner at gmail dot com

Description:

When using PDO prepare for mysql, quotes are incorrectly inserted
around column names, resulting in errors or unexpected results.  This
problem would have been _much_ easier to diagonise if there was a way of
seeing the actual statement.  Something like:
$string PDOStatement::executeString()---returns the statement that
would have been executed by PDOStatement::execute().

Reproduce code:
---
//given a mysql connection $pdo
//and a database table 'myTable' with columns: id, col1, col2, col3
//with a row: 1, value1, value2, value3.

$stmt=$pdo->prepare("SELECT ? FROM myTable WHERE id=?");
$myColumn = 'col1';
$stmt->execute(array($myColumn, 1));
$row=$stmt->fetch();
print_r($row);

Expected result:

I'd expect to see: "value1" displayed, as you'd expect for the
statement: "SELECT col1 FROM myTable WHERE id=1"

Actual result:
--
What is displayed is: "col1", as you'd expect for the statement:
"SELECT 'col1' FROM myTable WHERE id=1"

Other statements result in errors.  Example:
$stmt=$pdo->prepare("UPDATE myTable SET ?=? WHERE id=?");
$stmt->execute(array($myColumn, $myValue, $myId));

is a syntax error, as is the SQL:
UPDATE myTable SET 'col1'=3 WHERE id=1;

This problem means that I cant use prepare and execute statements at
all.





-- 
Edit this bug report at http://bugs.php.net/?id=49381&edit=1

#49381 [Opn]: PDO mysql prepare incorrectly quoting

[uw]

 ID:   49381
 Updated by:   u...@php.net
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

"The 'efficiency payoff' I was talking about is mentioned in various
prepared statement documentation.  The DB engine is meant to be able
to
save some prep time.  Obviously mysql would not be saving time if
'column parameter markers' were allowed in PDO."

Not every database supports prepared statements. And depending on the
MySQL version not all statements can be prepared. Some databases offer
named parameters others don't. MySQL doesn't. To overcome all the
differences between the various databases PDO has to have an emulation
layer. 

If the emulation gets used, you don't have server side prepared
statments. Its kind of client side prepared statements. The two concepts
are different. And, yes, with client side prepared statements you don't
benefit from certain DB caches. However, different DB engines, different
benefits of prepared statements vs. "regular" statements. 

In case of MySQL the time from getting a statement to start of query
execution is rather short. The benefit of the prepare can be small.


Previous Comments:


[2009-09-18 15:35:44] eprayner at gmail dot com

A few comments about that.  I think the PDO should attempt to be clear
about what is supported and what isn't.  If something doesn't work
everywhere, that should be noted.

The 'efficiency payoff' I was talking about is mentioned in various
prepared statement documentation.  The DB engine is meant to be able to
save some prep time.  Obviously mysql would not be saving time if
'column parameter markers' were allowed in PDO.

'The PDO SQL parser is provided by the PDO core.'  Really?  I thought
it'd just translate to mysql prepared statements!?! Sure I read that
somewhere.  Either way, it could be fixed.

'What happens in this case is that PDO parses your statement,
recognizes a placeholder and tries to replace it with the bound value.
To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen.'

I don't mind 'escaping', the final string should not be quoted though.

'...take the safe but stony road of improving the PDO parser and teach
it (for all SQL dialects!) what an identifier is.'
Surely you've got to translate to an SQL dialect at some point.  The
trick is to do it right!--Not quote mysql identifiers for example.



[2009-09-18 12:42:12] u...@php.net

PDO is an API abstraction layer. It neither does abstract SQL
differences nor does PDO pay much attention to provide a unified type
system. Users need to pay attention to differences between SQL dialects
on their own.

I understand that it would be helpful to have summary on SQL
differences somewhere but on the other hand I would understand the
documentation team to just link to any such document but keep details
itself out of the core documentation. Just my thoughts...

I am not sure what you mean by "efficiency payoff". A client side
emulation of PS has different properties than server side PS. IMHO there
is no clear line on what is preferrable. 

The PDO SQL parser is provided by the PDO core. This is a tricky design
decision because it is one SQL parser for all the different SQL
dialects. The PDO SQL parser is very generic and you can find edge cases
in the bug system where it fails. 

Even if the client side emulation may give you a feature you want, you
should be aware of the overall design and not forget about its
limitations.

What happens in this case is that PDO parses your statement, recognizes
a placeholder and tries to replace it with the bound value. To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen. 

Two solutions come to my mind: either you allow users to hint PDO that
nothing shall be escaped or you take the safe but stony road of
improving the PDO parser and teach it (for all SQL dialects!) what an
identifier is. Both solutions would require changing the core of PDO.



[2009-09-18 10:46:45] eprayner at gmail dot com

OK.  At http://dev.mysql.com/doc/refman/5.1/en/prepare.html
it says 'Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.'
So either this is a restriction for php PDOs, in which case it should
be explained in the documentation, or it is a problem with php's 'PDO
prepared statement emulation par

#45289 [NoF->Bgs]: Cannot use prepared statements and fetch_row together

[uw]

 ID:   45289
 Updated by:   u...@php.net
 Reported By:  mike dot benza at rice dot edu
-Status:   No Feedback
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: *
 PHP Version:  5.2.4
 New Comment:

In this case mysql_store_result() should not return a result set.
Closing because it is a matter of the MySQL Client Library and not PHP.
See also http://bugs.mysql.com/bug.php?id=47485 . 


Previous Comments:


[2009-05-28 18:16:30] u...@php.net

I think its bogus. Wrong use of the API. The critical part here is that
you get a result set at all...



[2009-05-15 19:55:28] jochen dot wiedmann at gmail dot com

I have checked the latest snapshot (php5.2-200905151830), whether the
problem still persists by using the script below. (Should be easy to
derive a .phpt file from it.)

real_connect("localhost", "root", null, 'test');
  if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
  }
  $mysqli->query("DROP TABLE IF EXISTS prep_and_fetch_row")
or die($mysqli->error);
  $mysqli->query("CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL)")
or die($mysqli->error);
  $mysqli->query("INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc')")
or die($mysqli->error);
  $stmt = $mysqli->prepare("SELECT * FROM prep_and_fetch_row WHERE
id=?")
or die($mysqli->error);
  $id = "1";
  $stmt->bind_param("i", $id)  or die($mysqli->error);
  $stmt->execute() or die($mysqli->error);
  $result = $mysqli->use_result() or die($mysqli->error);
  while ($row = $result->fetch_row()) {
print "- result row ---\n";
print_r($row);
  }
  print "- no more results ---\n";

  $mysqli->query("DROP TABLE prep_and_fetch_row") or
die($mysqli->error);
  $mysqli->close();
?>

Expected output: Something like

- result row ---
Array
(
[0] => int(1)
[1] => string(3) "abc"
)
- no more results ---

Actual output:

- result row ---
Array
(
[0] => 
[1] => 
)
- no more results ---

I'd consider this to be a clear bug.



[2009-05-15 13:39:22] jochen dot wiedmann at gmail dot com

I have the same problem with PHP 5.2.6, as delivered with Fedora 10
Linux.



[2008-07-22 01:00:02] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2008-07-14 21:05:49] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





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/45289

-- 
Edit this bug report at http://bugs.php.net/?id=45289&edit=1

#49562 [Bgs]: mysql_info() hides warnings for single-row INSERT's

[uw]

 ID:   49562
 Updated by:   u...@php.net
 Reported By:  jille at hexon dot cx
 Status:   Bogus
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  5.3.0
 New Comment:

Yes, you need to run SHOW WARNINGS or similar. If you want this to be
changed, please file a feature request at bugs.mysql.com. It is not a
PHP bug.


Previous Comments:


[2009-09-21 10:04:41] jille at hexon dot cx

Can you tell me how to retreive the number of warnings without querying
'SHOW WARNINGS' ?
I think mysql_info() is the place where that should be available.



[2009-09-17 11:47:45] u...@php.net

Please see http://bugs.php.net/bug.php?id=49573 for an explanation.

mysql_info() does not return anything for single-row INSERTs and that
is how it should be.



[2009-09-16 07:34:50] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-09-15 13:08:24] jille at hexon dot cx

Description:

mysql_info() returns false when inserting only one row. This results in
the unability to retreive the number of warnings which might have
occurred.

if $numWarnings > 0 I would like to retreive the warnings with
mysql_query("SHOW WARNINGS"); but I'd prefer not doing that if there are
no warnings.

Reproduce code:
---
mysql_query("CREATE TABLE a (a VARCHAR(4))");
mysql_query("INSERT INTO a (a) VALUES ('abcde')");
var_dump(mysql_info());

Expected result:

Just like the mysql-CLI:

mysql> INSERT INTO a (a) VALUES ('abcde');
Query OK, 1 row affected, 1 warning (0.01 sec)

so something like "1 row affected, 1 warning" would be perfect

Actual result:
--
bool(false)






-- 
Edit this bug report at http://bugs.php.net/?id=49562&edit=1

#49262 [Opn]: PDO MySQL doesn't take STRING params

[uw]

 ID:   49262
 Updated by:   u...@php.net
 Reported By:  grzegorz at heex dot pl
 Status:   Open
 Bug Type: PDO related
 Operating System: Win XP Sp3
 PHP Version:  5.3.0
 New Comment:

Ok, great. Your character set is uft8 (uft8_general_ci is the
collation). 

Can you paste "SHOW VARIABLES LIKE '%character%'" to give details about
your MySQL settings?

Thanks!


Previous Comments:


[2009-09-20 22:44:06] grzegorz at heex dot pl

Column lng_name and a whole table they have utf8_general_ci charset.



[2009-09-18 08:39:34] u...@php.net

Can you say anything about the character sets you are using?



[2009-08-25 07:57:54] grzegorz at heex dot pl

FunctionArg 1   Arg 2   Arg 3 Source
php5ts!mysqlnd_cset_escape_slashes+30   05652000   
0565fb58  
php_pdo_mysql!_pdo_mysql_error+6f7  0565f5880565fb58   
0006  
php5ts!pdo_parse_params+394 05662d5005662e780026
  
php5ts!pdo_stmt_describe_columns+7720565f638   
  
php5ts!execute+10b9 05690070015e5801007f66b8  
php5ts!execute+156d 015e585803e8fbe0  
php5ts!execute+298  0565dbf0015e5800015e5858  
php5ts!zend_execute_scripts+fe  0008015e5858
 

php5ts!php_execute_script+231   03e8fe6c015e58580005
 

php5apache2_2!zm_info_apache+1744   007aa7600073a400   
007aa760  
libhttpd!ap_run_handler+21  007aa760007aa760007aa760
  
libhttpd!ap_invoke_handler+ae   007a771803e8ff38
 

libhttpd!ap_die+24e 007aa7600073aac8  
libhttpd!ap_get_request_note+1c6c   007a7718007a7718   
007a7718  
libhttpd!ap_run_process_connection+21   007a77180074a198   
03e8ff80  
libhttpd!ap_process_connection+33   007a7718007a26d8   
0006fb80  
libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80   
00eb0650  
msvcrt!_endthreadex+a9  0079ef880006fb8000eb0650  
kernel32!BaseThreadStart+37 77c2a3410079ef88
  



PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In
httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in
C:\php5\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x0010 on thread 157



[2009-08-24 19:55:42] sjo...@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.





[2009-08-14 20:23:43] grzegorz at heex dot pl

Description:

Now, PDO in PHP 5.3 is usless.

Reproduce code:
---
$name = 'same_name';
$pdo= new
PDO("mysql:host=localhost;dbname=[base];",'[user]','[pass]');
$sth = $pdo->prepare("SELECT * FROM lng WHERE lng_name=:Name");
$sth->bindValue(':Name',$name,PDO::PARAM_STR);
$sth->execute();
die('OK');

Expected result:

OK

Actual result:
--
PHP CGI / FastCGI crash





-- 
Edit this bug report at http://bugs.php.net/?id=49262&edit=1

#48855 [Opn->Ver]: Decimals are rounded with PDO bindValue in mysql double/float fields

[uw]

 ID:   48855
 Updated by:   u...@php.net
 Reported By:  lorenzo-99 at libero dot it
-Status:   Open
+Status:   Verified
 Bug Type: PDO related
 Operating System: Windows XP
 PHP Version:  5.2.10
 New Comment:

That is a PDO bug not a PDO_MYSQL bug. It has been fixed in PHP 5.3+.

ext/pdo/pdo_stmt.c:330 needs something like this:

int len = spprintf(&p, 0, "%.*H", (int) EG(precision),
Z_DVAL_P(param->parameter));

I don't know what the policy is with PHP 5.2. Would be nice if someone
else could apply the patch. I am quite sure to have seen this bug before
and I am also sure the 5.3 tests cover it. Though, I can't say which
test from top of my head. 


Previous Comments:


[2009-07-08 16:48:03] lorenzo-99 at libero dot it

Description:

I'm inserting a new record in a Mysql table with a PDO routine, the
table have a double field (not specified the scale and size for the
field), I'm using the bindValue function, I try to save the value
9.1234567 in the field, after the insert I found it saves 9.123457, so
maximum 6 decimals (with rounding). 

The same problem happens with a float field, in this case it saves
maximum 5 decimals

I didn't try with other dbms, my Mysql version is 5.1.36 (i verified
that the problem happens also with older versions)

Reproduce code:
---
This saves only 6 decimal (using bindValue):
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', :value)");

/*** bind values ***/
$sth->bindValue(':value', 9.1234567, PDO::PARAM_STR);

/*** execute the prepared statement ***/
$sth->execute();

This saves all decimals (without bindValue)
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', 9.1234567)");

/*** execute the prepared statement ***/
$sth->execute();






-- 
Edit this bug report at http://bugs.php.net/?id=48855&edit=1

#49262 [Opn]: PDO MySQL doesn't take STRING params

[uw]

 ID:   49262
 Updated by:   u...@php.net
 Reported By:  grzegorz at heex dot pl
 Status:   Open
 Bug Type: PDO related
 Operating System: Win XP Sp3
 PHP Version:  5.3.0
 New Comment:

Thanks again, utf8 everywhere. We guessed so. 

I don't know if its of much relevance but one last question: what
version of MySQL 6.0 are you using?

.oO( MySQL 6.0 is something I don't like to see here. I wouldn't want
to debug a non-GA server, if I had a choice. )

Thanks!


Previous Comments:


[2009-09-22 16:35:59] grzegorz at heex dot pl

Variable_name   Value
character_set_clientutf8
character_set_connectionutf8
character_set_database  utf8
character_set_filesystembinary
character_set_results   utf8
character_set_serverutf8
character_set_systemutf8
character_sets_dir  C:\Program Files\MySQL\MySQL Server
6.0\share\char..



[2009-09-22 13:53:00] u...@php.net

Ok, great. Your character set is uft8 (uft8_general_ci is the
collation). 

Can you paste "SHOW VARIABLES LIKE '%character%'" to give details about
your MySQL settings?

Thanks!



[2009-09-20 22:44:06] grzegorz at heex dot pl

Column lng_name and a whole table they have utf8_general_ci charset.



[2009-09-18 08:39:34] u...@php.net

Can you say anything about the character sets you are using?



[2009-08-25 07:57:54] grzegorz at heex dot pl

FunctionArg 1   Arg 2   Arg 3 Source
php5ts!mysqlnd_cset_escape_slashes+30   05652000   
0565fb58  
php_pdo_mysql!_pdo_mysql_error+6f7  0565f5880565fb58   
0006  
php5ts!pdo_parse_params+394 05662d5005662e780026
  
php5ts!pdo_stmt_describe_columns+7720565f638   
  
php5ts!execute+10b9 05690070015e5801007f66b8  
php5ts!execute+156d 015e585803e8fbe0  
php5ts!execute+298  0565dbf0015e5800015e5858  
php5ts!zend_execute_scripts+fe  0008015e5858
 

php5ts!php_execute_script+231   03e8fe6c015e58580005
 

php5apache2_2!zm_info_apache+1744   007aa7600073a400   
007aa760  
libhttpd!ap_run_handler+21  007aa760007aa760007aa760
  
libhttpd!ap_invoke_handler+ae   007a771803e8ff38
 

libhttpd!ap_die+24e 007aa7600073aac8  
libhttpd!ap_get_request_note+1c6c   007a7718007a7718   
007a7718  
libhttpd!ap_run_process_connection+21   007a77180074a198   
03e8ff80  
libhttpd!ap_process_connection+33   007a7718007a26d8   
0006fb80  
libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80   
00eb0650  
msvcrt!_endthreadex+a9  0079ef880006fb8000eb0650  
kernel32!BaseThreadStart+37 77c2a3410079ef88
  



PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In
httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in
C:\php5\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x0010 on thread 157



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/49262

-- 
Edit this bug report at http://bugs.php.net/?id=49262&edit=1

#48855 [Ver->Csd]: Decimals are rounded with PDO bindValue in mysql double/float fields

[uw]

 ID:   48855
 Updated by:   u...@php.net
 Reported By:  lorenzo-99 at libero dot it
-Status:   Verified
+Status:   Closed
 Bug Type: PDO related
 Operating System: Windows XP
 PHP Version:  5.2.10
 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Hmm, seems to have been fixed before in SVN and in PHP 5.2.11:

if (PDO_PARAM_TYPE(param->param_type) == PDO_PARAM_STR &&
param->max_value_len <= 0 && ! ZVAL_IS_NULL(param->parameter)) {
if (Z_TYPE_P(param->parameter) == IS_DOUBLE) {
char *p;
int len = spprintf(&p, 0, "%.*H", (int)
EG(precision), Z_DVAL_P(param->parameter));
ZVAL_STRINGL(param->parameter, p, len, 0);
} else {
convert_to_string(param->parameter);
}



Previous Comments:


[2009-09-22 16:51:45] u...@php.net

That is a PDO bug not a PDO_MYSQL bug. It has been fixed in PHP 5.3+.

ext/pdo/pdo_stmt.c:330 needs something like this:

int len = spprintf(&p, 0, "%.*H", (int) EG(precision),
Z_DVAL_P(param->parameter));

I don't know what the policy is with PHP 5.2. Would be nice if someone
else could apply the patch. I am quite sure to have seen this bug before
and I am also sure the 5.3 tests cover it. Though, I can't say which
test from top of my head. 



[2009-07-08 16:48:03] lorenzo-99 at libero dot it

Description:

I'm inserting a new record in a Mysql table with a PDO routine, the
table have a double field (not specified the scale and size for the
field), I'm using the bindValue function, I try to save the value
9.1234567 in the field, after the insert I found it saves 9.123457, so
maximum 6 decimals (with rounding). 

The same problem happens with a float field, in this case it saves
maximum 5 decimals

I didn't try with other dbms, my Mysql version is 5.1.36 (i verified
that the problem happens also with older versions)

Reproduce code:
---
This saves only 6 decimal (using bindValue):
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', :value)");

/*** bind values ***/
$sth->bindValue(':value', 9.1234567, PDO::PARAM_STR);

/*** execute the prepared statement ***/
$sth->execute();

This saves all decimals (without bindValue)
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', 9.1234567)");

/*** execute the prepared statement ***/
$sth->execute();






-- 
Edit this bug report at http://bugs.php.net/?id=48855&edit=1

#47960 [Opn->Bgs]: PDO_MYSQL: cannot bind LIMIT or OFFSET

[uw]

 ID:   47960
 Updated by:   u...@php.net
 Reported By:  dan dot franklin at pearson dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PDO related
 Operating System: RHEL 5.3
 PHP Version:  5.2.9
 New Comment:

You are not telling PDO what type your parameter is and it defaults to
the safe choice of string. PDO escapes the string and you get the error.
Specify INT and it works.


Previous Comments:


[2009-04-30 06:20:44] balagod at gmail dot com

Hi,
i faced same problem.
i converted my parameters  as integer using typecast (int) it's
working.
$stcount=(int)$_POST['stcount'];
$ecount=10;
$selQry="SELECT * from TABLE where status=1 order by add_date limit
:offset,:rowcount";
$stmt=$conn->prepare($selQry);
$stmt->bindParam(':offset',$stcount,PDO::PARAM_INT);
$stmt->bindParam(':rowcount',$ecount,PDO::PARAM_INT);
$stmt->execute();



[2009-04-13 13:50:53] dan dot franklin at pearson dot com

Description:

In moving from PHP 5.1.6 to 5.2.9 I've lost the ability to bind to a
LIMIT or OFFSET parameter against MySQL 5.0; that is, if I have
   ... LIMIT ?
or
   ... OFFSET ?
it fails with
   You have an error in your SQL syntax; check the manual that
   corresponds to your MySQL server version for the right syntax to use
near ''3'' at line 1

(where "3" is the actual value of the parameter bound to the ?).

 

Reproduce code:
---
prepare($sql);
if (!$stmt) {
$i = $dbh->errorInfo();
print "Preparing \"$sql\" failed: $i[2]\n";
} else if (!$stmt->execute($params)) {
$i = $stmt->errorInfo();
print "Executing \"$sql\" failed: $i[2]\n";
} else {
print "\"$sql\" succeeded\n";
}
}
?>


Expected result:

"CREATE TABLE t (n int)" succeeded
"select n FROM t LIMIT ?" succeeded
"select n FROM t LIMIT 3 OFFSET ?" succeeded
"DROP TABLE t" succeeded

(This is what happens with PHP 5.1.6 MySql 5.0.45)

Actual result:
--
"CREATE TABLE t (n int)" succeeded
Executing "select n FROM t LIMIT ?" failed: You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near ''3'' at line 1
Executing "select n FROM t LIMIT 3 OFFSET ?" failed: You have an error
in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near ''3'' at line 1
"DROP TABLE t" succeeded

(With PHP 5.2.9 MySQL 5.0.77)





-- 
Edit this bug report at http://bugs.php.net/?id=47960&edit=1

#47960 [Bgs]: PDO_MYSQL: cannot bind LIMIT or OFFSET

[uw]

 ID:   47960
 Updated by:   u...@php.net
 Reported By:  dan dot franklin at pearson dot com
 Status:   Bogus
 Bug Type: PDO related
 Operating System: RHEL 5.3
 PHP Version:  5.2.9
 New Comment:

Whoever is right, let's close this report in favour of
http://bugs.php.net/bug.php?id=44639 . There are many duplicates. All
boil down to the default of string. Some of the previous reports have
been bogussed, AFAIK.


Previous Comments:


[2009-09-23 20:26:34] dan dot franklin at pearson dot com

No, the safe choice for PDO would be to use the native PHP type of the
variable, where there is a corresponding SQL type. That would be
sensible default behavior.  I changed my PDO interface library to do
this and it works perfectly. PDO ought to work the same way.



[2009-09-23 20:15:20] u...@php.net

You are not telling PDO what type your parameter is and it defaults to
the safe choice of string. PDO escapes the string and you get the error.
Specify INT and it works.



[2009-04-30 06:20:44] balagod at gmail dot com

Hi,
i faced same problem.
i converted my parameters  as integer using typecast (int) it's
working.
$stcount=(int)$_POST['stcount'];
$ecount=10;
$selQry="SELECT * from TABLE where status=1 order by add_date limit
:offset,:rowcount";
$stmt=$conn->prepare($selQry);
$stmt->bindParam(':offset',$stcount,PDO::PARAM_INT);
$stmt->bindParam(':rowcount',$ecount,PDO::PARAM_INT);
$stmt->execute();



[2009-04-13 13:50:53] dan dot franklin at pearson dot com

Description:

In moving from PHP 5.1.6 to 5.2.9 I've lost the ability to bind to a
LIMIT or OFFSET parameter against MySQL 5.0; that is, if I have
   ... LIMIT ?
or
   ... OFFSET ?
it fails with
   You have an error in your SQL syntax; check the manual that
   corresponds to your MySQL server version for the right syntax to use
near ''3'' at line 1

(where "3" is the actual value of the parameter bound to the ?).

 

Reproduce code:
---
prepare($sql);
if (!$stmt) {
$i = $dbh->errorInfo();
print "Preparing \"$sql\" failed: $i[2]\n";
} else if (!$stmt->execute($params)) {
$i = $stmt->errorInfo();
print "Executing \"$sql\" failed: $i[2]\n";
} else {
print "\"$sql\" succeeded\n";
}
}
?>


Expected result:

"CREATE TABLE t (n int)" succeeded
"select n FROM t LIMIT ?" succeeded
"select n FROM t LIMIT 3 OFFSET ?" succeeded
"DROP TABLE t" succeeded

(This is what happens with PHP 5.1.6 MySql 5.0.45)

Actual result:
--
"CREATE TABLE t (n int)" succeeded
Executing "select n FROM t LIMIT ?" failed: You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near ''3'' at line 1
Executing "select n FROM t LIMIT 3 OFFSET ?" failed: You have an error
in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near ''3'' at line 1
"DROP TABLE t" succeeded

(With PHP 5.2.9 MySQL 5.0.77)





-- 
Edit this bug report at http://bugs.php.net/?id=47960&edit=1

#40740 [NoF]: PDO::execute() errors when parameters are used in LIMIT clause

[uw]

 ID:   40740
 Updated by:   u...@php.net
 Reported By:  phpbugs at filofox dot com
 Status:   No Feedback
 Bug Type: PDO related
 Operating System: Linux Debian Sarge 3.1
 PHP Version:  5.2.1
 Assigned To:  wez
 New Comment:

Can we close it as a duplicate and if favour of
http://bugs.php.net/bug.php?id=44639 ?


Previous Comments:


[2009-09-08 13:00:43] weblab dot solutions at gmail dot com

And I really surprised this issue not fixed for more than 2 year.



[2009-09-08 12:56:51] weblab dot solutions at gmail dot com

Try PHP 5.2.9 & 5.3.0 - get the same exception.



[2009-08-26 16:36:34] seb117 at free dot fr

I don't understand why this bug does not solved ? It's very important,
and we don't use PDO properly with this bug.



[2009-08-22 05:59:07] marcel dot esser at gmail dot com

Same problem on 5.2.6, Ubuntu Jaunty.



[2009-06-16 17:49:09] tony at tonybibbs dot com

Same issue on 5.3.0RC2 using pretty much the same code in the initial
bug report.



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/40740

-- 
Edit this bug report at http://bugs.php.net/?id=40740&edit=1

#43752 [NoF]: PDO bindParam Mangles bound objects

[uw]

 ID:   43752
 Updated by:   u...@php.net
 Reported By:  motoma at gmail dot com
 Status:   No Feedback
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.2CVS-2008-01-04 (snap)
 New Comment:

A duplicate of http://bugs.php.net/bug.php?id=41027 ?


Previous Comments:


[2009-02-21 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".



[2009-02-13 22:22:17] fel...@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-01-15 18:22:12] motoma at gmail dot com

I will have to check later.
I doubt that this is the same error, this error is related directly to
the utilization of __toString() in PDO's bindParam() function.



[2008-01-15 15:14:06] mjs at beebo dot org

Does the mangling happen without the ATTR_PERSISTENT?  It looks like
this may be related to:

http://bugs.php.net/bug.php?id=43831

which concerns $this getting mangled



[2008-01-04 18:32:58] motoma at gmail dot com

Description:

I built a class with a __toString() member function. When I pass an
instance of this class to bindParam(), the object is overwritten with
the result of __toString().

The result from the code sample suggests that bindParam is overwriting
the value of the object with the object's __toString() value.

Reproduce code:
---
a);
}
}

$db = new PDO('mysql:host=localhost;dbname=test', 'root', '',
array(PDO::ATTR_PERSISTENT => true));
$obj = new test();

$prepared = $db->prepare('SELECT * FROM table1 WHERE 1 = :test');

var_dump($obj);
$prepared->bindParam('test', $obj);
var_dump($obj);
?>

Expected result:

object(test)#2 (1) {
  ["a:private"]=>
  int(1)
}
object(test)#2 (1) {
  ["a:private"]=>
  int(1)
}

Actual result:
--
object(test)#2 (1) {
  ["a:private"]=>
  int(1)
}
string(1) "1"





-- 
Edit this bug report at http://bugs.php.net/?id=43752&edit=1

#47224 [Asn->Csd]: MYSQL_ATTR_INIT_COMMAND is no longer available

[uw]

 ID:   47224
 Updated by:   u...@php.net
 Reported By:  contact at joycebabu dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.3.0alpha3
 Assigned To:  mysql
 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.

http://news.php.net/php.cvs/60481


Previous Comments:


[2009-08-31 09:38:43] and...@php.net

mysqlnd did not support in 5.3.0 INIT_COMMAND, support is already in
svn however and will be part of 5.3.1, but PDO needs to export and use
that functionality.



[2009-08-20 15:20:29] emma dot foster-bouz38wu at yopmail dot com

Reproduced with PHP5.3.1 on Windows XP 32bits.



[2009-07-31 06:31:07] nitel_defect at yahoo dot com

I subscribe, the 1002 fix does not work: Windows 7 x64, PHP 5.3.0,
MySQL 5.1.36



[2009-07-17 00:34:23] techi at techi dot name

Using 1002 instead of constant does not work either. Using 5.3.0 under

x64 Windows



[2009-07-02 10:43:36] mg at artigo dot pl

A temporary solution is to use INT value (1002) instead of constant.



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/47224

-- 
Edit this bug report at http://bugs.php.net/?id=47224&edit=1

#48934 [NoF]: mysqli::real_escape_string causes Apache to crash

[uw]

 ID:   48934
 Updated by:   u...@php.net
 Reported By:  volumnet at olympus dot ru
 Status:   No Feedback
 Bug Type: MySQLi related
 Operating System: Windows XP SP3
 PHP Version:  5.3.0
 New Comment:

Win, mysqlnd, MySQL 6.0, escape - smells like
http://bugs.php.net/49262



Previous Comments:


[2009-07-29 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".



[2009-07-21 23:18:42] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-07-15 20:06:08] volumnet at olympus dot ru

Description:

MySQLi function real_escape_string causes an internal server error

I'm using:
- VC6 x86 PHP 5.3.0 Windows binary (the problem there is both on thread
safe and non thread safe versions) with MySQLi extension support
- Apache 2.2.10
- MySQL 6.0.7 alpha



Reproduce code:
---
real_escape_string('aaa');
?>

or



Expected result:

the code expected to return the string "aaa" like in PHP 5.2.x

Actual result:
--
while executing it causes Error 500 (Internal Server Error), with
"Premature end of script headers: php-cgi.exe" entry in Apache error
log.





-- 
Edit this bug report at http://bugs.php.net/?id=48934&edit=1

#49651 [Opn->Csd]: "IN" statment badly handled in bindValue

[uw]

 ID:   49651
 Updated by:   u...@php.net
 Reported By:  mmarais at centrapel dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Linux version 2.6.18-6-686 (Debi
 PHP Version:  5.2.11
 New Comment:

Closing because it is a duplicate of
http://bugs.php.net/bug.php?id=44639 . Please follow up in the other bug
report.

A workaround is to specify the type of the parameter explicitly. 


Previous Comments:


[2009-09-24 08:48:18] mmarais at centrapel dot com

Description:

Using named paramters with the "IN" statement does not work correctly.
Is a list is used as a parameter with bindValue this list is interpreted
as a quoted string in the sql command

Reproduce code:
---
$arrEmployees = array(1,2,3,4,5,6);

$strSQL = "
   SELECT id, name
   FROM   employees
   WHERE  id in (:my_list);
";

$objPDOStatement = $objPDO->prepare($strSQL);
$objPDOStatement -> bindValue(':my_list', implode(',',
$arrEmployees));
$objPDOStatement -> execute();

Expected result:

--
id | name
--
 1 | John Doe
 2 | Jack Doe
 3 | Gill Doe
 4 | Ralf Doe
 5 | Sven Doe
 6 | Carl Doe
--

Actual result:
--
--
id | name
--
 1 | John Doe
--

In sql cli, same results as if running  

   SELECT id, name
   FROM   employees
   WHERE  id in ('1,2,3,4,5,6'); -- List with quotes;

when expecting

   SELECT id, name
   FROM   employees
   WHERE  id in (1,2,3,4,5,6); -- List with no quotes;






-- 
Edit this bug report at http://bugs.php.net/?id=49651&edit=1

#44639 [Opn]: PDO quotes integers in prepared statement

[uw]

 ID:   44639
 Updated by:   u...@php.net
 Reported By:  jgauld at blueyonder dot co dot uk
 Status:   Open
 Bug Type: PDO related
-Operating System: WinXP
+Operating System: All
-PHP Version:  5.2.10
+PHP Version:  Any > 5.1.x
 New Comment:

Related reports: http://bugs.php.net/bug.php?id=49651 ,
http://bugs.php.net/49381


Previous Comments:


[2009-09-22 21:18:23] sjo...@php.net

The third parameter to bindValue defaults to PDO::PARAM_STR. This is
different than the original bug reporter said, so it must be changed in
the meantime. Because the datatype is PDO::PARAM_STR, the int is cast to
a string and quoted.

It would make sense to use the PHP type to determine the most logical
PDO::PARAM_* type. See also bug #44597, which is essentially the same
problem but with booleans and execute() instead of bindValue().



[2009-08-17 17:38:15] j...@php.net

But you didn't bother updating the version field. Done now..



[2009-07-21 00:30:49] whistl0r+php at googlemail dot com

Hi,

this bug is still present in the current PHP version.
Tested with PHP 5.2.10 stable and snapshot on Windows.

MySQL client api: 5.1.35



[2008-10-21 11:59:03] jgauld at blueyonder dot co dot uk

Tried windows snapshot as suggested (5.2.7RC2-dev), but no joy. Result
is same, ie:

select * from my_table where id>'13'

If it helps, phpinfo() reports:

PDO Driver for MySQL, client library version5.0.51a



[2008-07-03 15:17:35] u...@php.net

This is not a driver issue. Its the PDO SQL driver messing up SQL
statements.



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/44639

-- 
Edit this bug report at http://bugs.php.net/?id=44639&edit=1

#47712 [Asn]: (mysqlnd) zval cache on windows fails at high concurrency

[uw]

 ID:   47712
 Updated by:   u...@php.net
 Reported By:  ninzya at inbox dot lv
 Status:   Assigned
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC2
 Assigned To:  mysql
 New Comment:

>From our earlier benchmarking I recall that zval caching does give a
big performance boost if any at all. We might even remove it altogether.
So, potential bug in code that may be removed...


Previous Comments:


[2009-06-22 00:50:51] paj...@php.net

See my comment in the other bug, there was no bug but only a wrong
impression that the memory usage has been increased.



[2009-06-19 08:13:23] ninzya at inbox dot lv

Changed bug summary. zval cache is still not fixed on windows. Changed
bug status to "Open".



[2009-06-15 10:33:55] ninzya at inbox dot lv

For example, this one

http://bugs.php.net/bug.php?id=48525

I have seen some more bug reports just after you have turned off zval
cache and committed to CVS, i can't find them right now.



[2009-06-15 10:14:33] and...@php.net

Can you be more specific about these memory leaks?



[2009-06-14 11:31:32] ninzya at inbox dot lv

People started reporting memory leaks when working with mysql (through
PDO, mysqli, mysql). I didn't try to investigate this issue, but i
assume the leaks may have taken place after andrey has switched zval
cache to off. You should take a look at this. See some bug reports after
andrey has posted about the change he has made to CVS.



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/47712

-- 
Edit this bug report at http://bugs.php.net/?id=47712&edit=1

#48855 [Opn->Fbk]: Decimals are rounded with PDO bindValue in mysql double/float fields

[uw]

 ID:   48855
 Updated by:   u...@php.net
 Reported By:  lorenzo-99 at libero dot it
-Status:   Open
+Status:   Feedback
 Bug Type: PDO related
 Operating System: Windows XP
 PHP Version:  5.2.10
 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:


[2009-09-25 13:58:37] lorenzo-99 at libero dot it

Sorry but The Problem in 5.3 is NOT fixed.

I tried first to install 5.2.11 and i verified that the problem is
fixed, then I update to 5.3 but the problem here still exists

I download the windows version from http://windows.php.net/download/

php-5.3.0-Win32-VC6-x86.zip thread-safe

The strange thing I see is that 5.3 is dated 2009-jun-30 while 5.2.11
is more recent 2009-sep-17



[2009-09-23 10:32:05] u...@php.net

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Hmm, seems to have been fixed before in SVN and in PHP 5.2.11:

if (PDO_PARAM_TYPE(param->param_type) == PDO_PARAM_STR &&
param->max_value_len <= 0 && ! ZVAL_IS_NULL(param->parameter)) {
if (Z_TYPE_P(param->parameter) == IS_DOUBLE) {
char *p;
int len = spprintf(&p, 0, "%.*H", (int)
EG(precision), Z_DVAL_P(param->parameter));
ZVAL_STRINGL(param->parameter, p, len, 0);
} else {
convert_to_string(param->parameter);
}




[2009-09-22 16:51:45] u...@php.net

That is a PDO bug not a PDO_MYSQL bug. It has been fixed in PHP 5.3+.

ext/pdo/pdo_stmt.c:330 needs something like this:

int len = spprintf(&p, 0, "%.*H", (int) EG(precision),
Z_DVAL_P(param->parameter));

I don't know what the policy is with PHP 5.2. Would be nice if someone
else could apply the patch. I am quite sure to have seen this bug before
and I am also sure the 5.3 tests cover it. Though, I can't say which
test from top of my head. 



[2009-07-08 16:48:03] lorenzo-99 at libero dot it

Description:

I'm inserting a new record in a Mysql table with a PDO routine, the
table have a double field (not specified the scale and size for the
field), I'm using the bindValue function, I try to save the value
9.1234567 in the field, after the insert I found it saves 9.123457, so
maximum 6 decimals (with rounding). 

The same problem happens with a float field, in this case it saves
maximum 5 decimals

I didn't try with other dbms, my Mysql version is 5.1.36 (i verified
that the problem happens also with older versions)

Reproduce code:
---
This saves only 6 decimal (using bindValue):
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', :value)");

/*** bind values ***/
$sth->bindValue(':value', 9.1234567, PDO::PARAM_STR);

/*** execute the prepared statement ***/
$sth->execute();

This saves all decimals (without bindValue)
$sth = $dbh->prepare("INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', 9.1234567)");

/*** execute the prepared statement ***/
$sth->execute();






-- 
Edit this bug report at http://bugs.php.net/?id=48855&edit=1

#44289 [NoF->Bgs]: Output parameter not set if stored procedure returns rows

[uw]

 ID:   44289
 Updated by:   u...@php.net
 Reported By:  d at tpyo dot net
-Status:   No Feedback
+Status:   Bogus
 Bug Type: PDO related
 Operating System: Linux 2.6.22
 PHP Version:  5.2.5
 New Comment:

There is no bug here. 

You are not fetching the results from the SP and thus you get a
2014/Commands ouf of sync
(http://dev.mysql.com/doc/refman/5.1/en/error-messages-client.html). The
error gets reported through stmt->errorInfo(), as it should, when
running SELECT @test2. 

You must fetch the results from the SP and close the statement before
you can run a new query on the line. 

 


Previous Comments:


[2009-05-03 01:00:11] 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".



[2009-04-25 14:55:14] 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-02-29 10:40:07] d at tpyo dot net

Description:

It seems that if a stored procedure returns rows from a SELECT the
output parameters are lost.

Not sure if this is the intended behaviour, but since this works fine
from the MySQL CLI I'm inclined to believe it's not.

Reproduce code:
---
Stored procedures and PDO code for reproducing the problem:

http://undesigned.org.za/files/pdo-issue.phps


Expected result:

PDO_FOUND_ROWS_TEST_1(@test1): string(4) "Set!"
PDO_FOUND_ROWS_TEST_2(@test2): string(4) "Set!"


Actual result:
--
PDO_FOUND_ROWS_TEST_1(@test1): string(4) "Set!"
PDO_FOUND_ROWS_TEST_2(@test2): FAILED






-- 
Edit this bug report at http://bugs.php.net/?id=44289&edit=1

#47977 [Opn->Bgs]: bindParam, current(), next()

[uw]

 ID:   47977
 Updated by:   u...@php.net
 Reported By:  fhgvbrdyftgjhgtfr at gazeta dot pl
-Status:   Open
+Status:   Bogus
 Bug Type: PDO related
 Operating System: Unix
 PHP Version:  5.2.9
 New Comment:

"Binds a PHP variable to a corresponding named or question mark
placeholder in the SQL statement that was use to prepare the statement.
Unlike PDOStatement::bindValue(), the variable is bound as a reference
and will only be evaluated at the time that PDOStatement::execute() is
called.", http://de2.php.net/manual/en/pdostatement.bindparam.php

At the time that you call PDOStatement::execute() you have overwritten
the bound variables' value ($element) multi times. PDO does exactly what
is documented: it uses the last value of $element. 

Workaround: use bindValue() instead of bindParam().






Previous Comments:


[2009-09-27 19:54:45] fhgvbrdyftgjhgtfr at gazeta dot pl

true);
$array = array_diff($array2, array_keys($array3));
reset($array);
$stmt = $db->prepare('SELECT `name` FROM `table` WHERE `language` = ?
AND `code` IN(?, ?)');
$stmt->bindValue(1, 'en', PDO::PARAM_STR);
$element = current($array);
$stmt->bindParam(2, $element, PDO::PARAM_STR);
$element = next($array);
$stmt->bindParam(3, $element, PDO::PARAM_STR);
$stmt->execute();
var_dump($stmt->fetchAll());
?>
---
actual result:
array(1) {
  [0]=>
  array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
  }
}
---
expected result:
array(2) {
  [0]=>
  array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
  }
  [1]=>
  array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
  }
}
---
db:
CREATE TABLE `table` (
  `name` varchar(45) NOT NULL,
  `language` enum('en','fr') NOT NULL,
  `code` char(2) NOT NULL
);
INSERT INTO `table` (`name`, `language`, `code`) VALUES
('test', 'en', 'fr'),
('test', 'en', 'gb');
---
if you change

$stmt->bindParam(2, $element, PDO::PARAM_STR);
for
$stmt->bindValue(2, $element, PDO::PARAM_STR);

AND

$stmt->bindParam(3, $element, PDO::PARAM_STR);
for
$stmt->bindValue(3, $element, PDO::PARAM_STR);

you will receive expected result

i can't write it easier, so deal with it or just delete this report.



[2009-09-02 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".



[2009-08-25 17:52:38] sjo...@php.net

Thank you for your bug report.

Although you supplied code to reproduce the problem, it is more
complicated and longer than necessary. Please supply a short, complete
and understandable piece of code to reproduce the problem. This is to
make sure the problem is with PHP and not with the example.



[2009-05-16 01:20:50] fhgvbrdyftgjhgtfr at gazeta dot pl

true, 'de'=>true);
$array = array_diff($array2, array_keys($array3));
reset($array);
$size = count($array);
$in = '?';
for($i = 1; $i < $size; ++$i) $in .= ', ?';
$stmt = $db->prepare('SELECT `name` FROM `table` WHERE `language` = ?
AND `code` IN('.$in.')');
$stmt->bindValue(1, 'en', PDO::PARAM_STR);
$i = 1;
$element = current($array);
do {
$stmt->bindParam(++$i, $element, PDO::PARAM_STR);
} while(($element = next($array)) !== false);
$stmt->execute();
var_dump($stmt->fetchAll());
?>
-
expected result:
array(3) {
  [0]=>
  array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
  }
  [1]=>
  array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
  }
  [2]=>
  array(2) {
["name"]=>
string(4) "test"
[0]=>
string(4) "test"
  }
}

actual result:
array(0) {
}

db:
CREATE TABLE IF NOT EXISTS `table` (
  `name` varchar(45) NOT NULL,
  `language` enum('en','fr') NOT NULL,
  `code` char(2) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;


INSERT INTO `table` (`name`, `language`, `code`) VALUES
('test', 'en', 'gb'),
('test', 'en', 'nz'),
('test', 'en', 'us'),
('test', 'en', 'cz');



[2009-05-08 01:00:02] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



The remainder of the comments for this report are too long. To view
the rest of the co