Edit report at http://bugs.php.net/bug.php?id=54908&edit=1
ID: 54908
Updated by: fel...@php.net
Reported by: StevenHadfield at letu dot edu
Summary: DBLIB segfaults when GROUPing with 0 rows for
prepared statements
-Status: Open
+Status: Feedback
Type: Bug
Package: PDO related
Operating System: Fedora Rawhide
PHP Version: 5.3.6
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2011-05-23 15:18:04] StevenHadfield at letu dot edu
Description:
------------
I haven't fully figured out the cause of this problem, but for what I
can narrow it down, it's a bit of a remote case.
What I am experiencing is odd behavior when doing a PDO(DBLIB) prepared
statement on a SELECT query with a GROUP BY clause. As far as I can
tell, when the query would have returned 0 results, the query returns an
empty array, but the next time the query is run, I get the following
result (regardless of what the data should actually be):
array(1) {
[0]=>
array(2) {
["!"]=>
NULL
[0]=>
NULL
}
}
After this occurs, any attempt (whether explicit or implicit) to unset
the statement results in a segfault in Zend/zend_alloc.c:2028:
if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
I have also found that this only happens when the first execution of the
prepared statement results in a 0 row query. If the order of the
execution in the test script below is reversed so that a result is
returned, the prepared statement works fine from then on.
Another specific of this bug is that it only occurs with the GROUP BY
clause. The query will work fine if I have an aggregate function, but do
not have the GROUP BY column specified.
I have tried the query in a different query tool, and it works fine.
I also tried the script with the php5.3-201105231230 snapshot, but was
still having the issue.
This problem is similar to Bug #40639, but my problem seems more narrow
in focus. I also do not receive the same segfault as the other bug.
Test script:
---------------
<?php
$db = new PDO('dblib:host=server;dbname=db', 'user', 'pass');
$query = $db->prepare('SELECT COALESCE(SUM(tblTransaction.Amount), 0)
FROM tblTransaction INNER JOIN tblDiscount ON
tblTransaction.TransactionTypeID = tblDiscount.TransactionTypeID AND
tblDiscount.DiscountID = :DiscountID WHERE tblTransaction.Voided IS NULL
AND tblTransaction.RegistrationID = :RegistrationID GROUP BY
tblTransaction.RegistrationID');
// This combination does not exist together in the database
$execute = $query->execute(array(':DiscountID' => 1, ':RegistrationID'
=> 114));
echo "\nExecuted: " . ($execute ? 'Successful' : 'Failed') . "\n";
$results = $query->fetchAll();
var_dump($results);
// This combination does exist together in the database
$execute = $query->execute(array(':DiscountID' => 20, ':RegistrationID'
=> 114));
echo 'Executed: ' . ($execute ? 'Successful' : 'Failed') . "\n";
$results = $query->fetchAll();
var_dump($results);
unset($query);
echo 'Unset';
Expected result:
----------------
Executed: Successful
array(0) {
}
Executed: Successful
array(1) {
[0]=>
array(2) {
["computed"]=>
string(4) "5.00"
[0]=>
string(4) "5.00"
}
}
Unset
Actual result:
--------------
Executed: Successful
array(0) {
}
Executed: Successful
array(1) {
[0]=>
array(2) {
["!"]=>
NULL
[0]=>
NULL
}
}
Segmentation fault (core dumped)
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=54908&edit=1
