php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54908 DBLIB segfaults when GROUPing with 0 rows for prepared statements
Submitted: 2011-05-23 15:18 UTC Modified: 2013-02-18 00:34 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: StevenHadfield at letu dot edu Assigned:
Status: No Feedback Package: PDO related
PHP Version: 5.3.6 OS: Fedora Rawhide
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: StevenHadfield at letu dot edu
New email:
PHP Version: OS:

 

 [2011-05-23 15:18 UTC] 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)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-23 15:21 UTC] felipe@php.net
-Status: Open +Status: Feedback
 [2011-05-23 15:21 UTC] felipe@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2011-05-23 15:25 UTC] StevenHadfield at letu dot edu
-Status: Feedback +Status: Open
 [2011-05-23 15:25 UTC] StevenHadfield at letu dot edu
gdb backtrace:

#0  _zend_mm_free_int (heap=0xb2c310, p=0xe1b868) at /usr/src/debug/php-5.3.6/Zend/zend_alloc.c:2028
#1  0x00007fffef1d1b1e in free_statement (stmt=0xe1bb70) at /usr/src/debug/php-5.3.6/ext/pdo/pdo_stmt.c:2410
#2  0x00000000005d0f3f in zend_objects_store_del_ref_by_handle_ex (handle=2, handlers=<optimized out>)
    at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:220
#3  0x00000000005d0f63 in zend_objects_store_del_ref (zobject=0xe1aa08) at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:172
#4  0x00000000005a09f2 in _zval_dtor (zvalue=<optimized out>) at /usr/src/debug/php-5.3.6/Zend/zend_variables.h:35
#5  _zval_ptr_dtor (zval_ptr=0xe1c170) at /usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:443
#6  _zval_ptr_dtor (zval_ptr=0xe1c170) at /usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:432
#7  0x00000000005bb931 in zend_hash_del_key_or_index (ht=0x939ec8, arKey=<optimized out>, nKeyLength=<optimized out>, h=<optimized out>, 
    flag=<optimized out>) at /usr/src/debug/php-5.3.6/Zend/zend_hash.c:500
#8  0x000000000062b36a in ZEND_UNSET_VAR_SPEC_CV_HANDLER (execute_data=0x7fffeb09c050) at /usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:22511
#9  0x00000000005d1e2b in execute (op_array=0xe1b260) at /usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:107
#10 0x00007ffff1e78d6d in xdebug_execute (op_array=0xe1b260) at /usr/src/debug/php-pecl-xdebug-2.1.1/xdebug-2.1.1/xdebug.c:1268
#11 0x00000000005affb0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/debug/php-5.3.6/Zend/zend.c:1194
#12 0x000000000055d3b3 in php_execute_script (primary_file=0x7fffffffdd20) at /usr/src/debug/php-5.3.6/main/main.c:2268
#13 0x000000000042486e in main (argc=2, argv=0x7fffffffdf28) at /usr/src/debug/php-5.3.6/sapi/cli/php_cli.c:1193
 [2011-12-04 18:06 UTC] ssufficool@php.net
-Status: Open +Status: Feedback
 [2011-12-04 18:06 UTC] ssufficool@php.net
Please try using this snapshot:

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

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

PDO_DBLIB has been significantly redesigned in PHP 5.4. Many memory allocations were removed possibly resolving this issue.
 [2013-02-18 00:34 UTC] 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 "Open". Thank you.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Sun Jul 13 20:01:33 2025 UTC