Bug #54908 [Fbk->Opn]: DBLIB segfaults when GROUPing with 0 rows for prepared statements

2011-05-23 Thread StevenHadfield at letu dot edu
Edit report at http://bugs.php.net/bug.php?id=54908&edit=1

 ID: 54908
 User updated by:StevenHadfield at letu dot edu
 Reported by:StevenHadfield at letu dot edu
 Summary:DBLIB segfaults when GROUPing with 0 rows for
 prepared statements
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Fedora Rawhide
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

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  0x7fffef1d1b1e in free_statement (stmt=0xe1bb70) at
/usr/src/debug/php-5.3.6/ext/pdo/pdo_stmt.c:2410

#2  0x005d0f3f in zend_objects_store_del_ref_by_handle_ex
(handle=2, handlers=)

at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:220

#3  0x005d0f63 in zend_objects_store_del_ref (zobject=0xe1aa08)
at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:172

#4  0x005a09f2 in _zval_dtor (zvalue=) 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  0x005bb931 in zend_hash_del_key_or_index (ht=0x939ec8,
arKey=, nKeyLength=, h=, 

flag=) at
/usr/src/debug/php-5.3.6/Zend/zend_hash.c:500

#8  0x0062b36a 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  0x005d1e2b in execute (op_array=0xe1b260) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:107

#10 0x71e78d6d in xdebug_execute (op_array=0xe1b260) at
/usr/src/debug/php-pecl-xdebug-2.1.1/xdebug-2.1.1/xdebug.c:1268

#11 0x005affb0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.6/Zend/zend.c:1194

#12 0x0055d3b3 in php_execute_script
(primary_file=0x7fffdd20) at
/usr/src/debug/php-5.3.6/main/main.c:2268

#13 0x0042486e in main (argc=2, argv=0x7fffdf28) at
/usr/src/debug/php-5.3.6/sapi/cli/php_cli.c:1193


Previous Comments:

[2011-05-23 15:21:06] fel...@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: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:
---
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->ex

[PHP-BUG] Bug #54908 [NEW]: DBLIB segfaults when GROUPing with 0 rows for prepared statements

2011-05-23 Thread StevenHadfield at letu dot edu
From: 
Operating system: Fedora Rawhide
PHP version:  5.3.6
Package:  PDO related
Bug Type: Bug
Bug description:DBLIB segfaults when GROUPing with 0 rows for prepared 
statements

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:
---
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 bug report at http://bugs.php.net/bug.php?id=54908&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54908&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54908&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=54908&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54908&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=54908&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54908&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=54908&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=54908&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=54908&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=54908&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=54908&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=54908&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=54908&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54908&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=54908&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54908&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=54908&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=54908&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=54908&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=54908&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=54908&r=mysqlcfg