Edit report at https://bugs.php.net/bug.php?id=67348&edit=1
ID: 67348
Comment by: chealer at gmail dot com
Reported by: derick@php.net
Summary: Reading $dbc->stat modifies $dbc->affected_rows
Status: Open
Type: Bug
Package: MySQLi related
Operating System: Linux
PHP Version: 5.6Git-2014-05-27 (Git)
Block user comment: N
Private report: N
New Comment:
I should have specified this affected me while using XDebug on Windows (8.1). This happened when I
migrated an application from mysql to mysqli, which is its closest equivalent. And the reason why I
migrated from mysql is that I upgraded to 5.5... which deprecates the mysql extension!
Unfortunately, there will probably many others affected.
And unfortunately, the procedural style mysqli_affected_rows() is also affected, so the best
workarounds I see is to go back to mysql, go to PDO instead, or wrap the critical part of our
high-level query() function in big "DO NOT STEP THROUGH THIS CODE" comments. We
wouldn't have the last choice if we didn't use such a wrapper, so we're in fact among
the luckiest...
Previous Comments:
------------------------------------------------------------------------
[2015-06-30 16:17:41] chealer at gmail dot com
This is a recipe to make a developer crazy. You hit a bug in your code, add breakpoints to try
debugging it, and get crazy results. I can't believe this persists. I am experiencing this
under PHP 5.5.12.
This was reported by figiemmi to NetBeans Forums on 2012-11-24, but he did not specify which PHP
version he was using. This is visibly an old bug, but it's hard to believe it's always
been that way.
This was also reported against NetBeans: https://netbeans.org/bugzilla/show_bug.cgi?id=244714
Thank you very much for reporting, your test case and your analysis, Derick.
------------------------------------------------------------------------
[2015-06-21 21:31:29] stephan dot eicher at check24 dot de
We are affected by this bug and it's very important for us because our framework relies on
valid return values for "affected_rows".
We can reproduce this issue on Debian Jessie with package php5 (5.6.x) and xdebug installed.
------------------------------------------------------------------------
[2014-05-27 22:31:58] derick@php.net
Description:
------------
When a script reads $dbc->stat, subsequent reads of $dbc->affected_rows return a different
result.
This was first reported to me as Xdebug bug #1053: http://bugs.xdebug.org/view.php?id=1053. I traced
this back to the reading of ->stat as follows:
- Xdebug's debugging command "context_get" reads all the variables in the local scope
- For each object variable, the debug handlers are called (through Z_OBJDEBUG_PP): https://github.com/derickr/xdebug/blob/master/xdebug_var.c#L1725
- MySQLi debug handler loops over a list of properties: https://github.com/php/php-src/blob/master/ext/mysqli/mysqli_prop.c#L449
- The debug handler for affected_rows is at https://github.com/php/php-src/blob/master/ext/mysqli/mysqli_prop.c#L158
- The debug handler for stat is at https://github.com/php/php-src/blob/master/ext/mysqli/mysqli_prop.c#L256
- The debug handler for stat is defined at https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd.h#L212
- When I do *not* call "$foo = $dbc->stat", everything works.
- I can not created a work around, because the debug handler loops over all properties, and I have
no chance to prevent ->stat from being read from the Xdebug side.
Test script:
---------------
<?php
$dbc = mysqli_connect('localhost', 'root', 'passwd',
'test');
$q = "INSERT INTO test1053 VALUES(7)";
$r = mysqli_query($dbc, $q);
var_dump($dbc->affected_rows);
$foo = $dbc->stat;
var_dump($dbc->affected_rows);
?>
Expected result:
----------------
int(1)
int(1)
Actual result:
--------------
int(1)
int(-1)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=67348&edit=1