Bug #67130 [Com]: nextRowset causes memory corruption
Edit report at https://bugs.php.net/bug.php?id=67130&edit=1
ID: 67130
Comment by: miracle at rpz dot name
Reported by: kaido at tradenet dot ee
Summary: nextRowset causes memory corruption
Status: No Feedback
Type: Bug
Package: PDO DBlib
Operating System: linux
PHP Version: master-Git-2014-04-24 (Git)
Assigned To: ssufficool
Block user comment: N
Private report: N
New Comment:
Fixed in #69757
Previous Comments:
------------------------------------------------------------------------
[2015-07-06 19:59:04] John_Schlick at hotmail dot com
I have experienced this problem on PHP 5.5.9-1ubuntu4.5 using the PDO
A stored procedure results in a variable number of rowsets, (in this case, 3), on the 3rd call to
nextrowset it returns true, so when I then trustingly do:
$result = $stmt->fetch(\PDO::FETCH_OBJ);
it results in:
SQLSTATE[HY000]: General error
------------------------------------------------------------------------
[2014-12-30 10:42:31] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
------------------------------------------------------------------------
[2014-10-23 03:39:12] ssufficool@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Fixed along with Bug #64511
------------------------------------------------------------------------
[2014-10-21 03:57:11] ssufficool@php.net
Instead of strdup I would null the col name pointers to (hopefully) cause pdo core to skip the
deallocate. I would hate to introduce an ever so slight performance penalty with a strdup if not
*absolutely* needed.
------------------------------------------------------------------------
[2014-04-26 08:29:14] kaido at tradenet dot ee
the problem/bug is as follows:
(1) ext/pdo/pdo_stmt.c:pdo_stmt_do_next_rowset() frees column names with efree()
(2) column names are set in ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_describe() with direct call to
dbcolname(). the returned name points to a fixed structure and as such does not need to be freed
later.
(3) ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_cursor_closer() and
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_stmt_dtor() know the fact (2) and do not free column names
(4) it seems that pdo expects the column names to be allocated - other drivers (oci, mysql etc) do
it this way.
so the proposed solution/fix would be:
(a) in ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_describe() estrdup() the column name as follows:
col->name = (char*)estrdup(dbcolname(H->link, colno+1));
b) add the code:
struct pdo_column_data *cols = stmt->columns;
int i;
for (i = 0; i < stmt->column_count; i++) {
efree(cols[i].name);
}
into ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_cursor_closer() and
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_stmt_dtor() to free column names in those code paths.
Can someone with better knowledge of the code here take a look, confirm my observations, and commit
the fix, please.
------------------------------------------------------------------------
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=67130
--
Edit this bug report at https://bugs.php.net/bug.php?id=67130&edit=1
Thread (9 messages)