php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51870 PDO::fetchAll after a PDO::execute with bindings lead to a segv.
Submitted: 2010-05-20 11:44 UTC Modified: 2010-05-25 10:46 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: dsp@php.net Assigned: mysql (profile)
Status: Closed Package: PDO related
PHP Version: 6SVN-2010-05-20 (SVN) OS: Mac OS X
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
6 + 7 = ?
Subscribe to this entry?

 
 [2010-05-20 11:44 UTC] dsp@php.net
Description:
------------
#0  0x00007fff83c74886 in __kill ()
#1  0x00007fff83d14eae in abort ()
#2  0x00007fff83c2ca75 in free ()
#3  0x00000001001b8328 in pdo_mysql_stmt_fetch (stmt=0x100d3ef18, 
ori=PDO_FETCH_ORI_NEXT, offset=0) at 
/Users/dsp/dev/c/php/trunk/ext/pdo_mysql/mysql_statement.c:655
#4  0x00000001001ac47a in do_fetch_common (stmt=0x100d3ef18, 
ori=PDO_FETCH_ORI_NEXT, offset=0, do_bind=1) at 
/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:694
#5  0x00000001001adaa1 in do_fetch (stmt=0x100d3ef18, do_bind=1, 
return_value=0x100d4eff8, how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT, offset=0, 
return_all=0x0) at /Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:861
#6  0x00000001001b0388 in zim_PDOStatement_fetchAll (ht=0, 
return_value=0x100d3f888, return_value_ptr=0x0, this_ptr=0x100d3a120, 
return_value_used=0) at 
/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:1560
#7  0x0000000100465e48 in execute_internal (execute_data_ptr=0x101b2a080, 
return_value_used=0) at /Users/dsp/dev/c/php/trunk/Zend/zend_execute.c:1468
#8  0x00000001004176d7 in dtrace_execute_internal (execute_data_ptr=0x101b2a080, 
return_value_used=0) at /Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:99
#9  0x0000000100467b04 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x101b2a080) at zend_vm_execute.h:359
#10 0x0000000100468eeb in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(execute_data=0x101b2a080) at zend_vm_execute.h:467
#11 0x00000001004663af in execute (op_array=0x100d3c030) at 
zend_vm_execute.h:129
#12 0x00000001004175e2 in dtrace_execute (op_array=0x100d3c030) at 
/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:75
#13 0x000000010042fb2d in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /Users/dsp/dev/c/php/trunk/Zend/zend.c:1210
#14 0x00000001003a31fd in php_execute_script (primary_file=0x7fff5fbfe9f0) at 
/Users/dsp/dev/c/php/trunk/main/main.c:2324
#15 0x000000010056caf4 in main (argc=2, argv=0x7fff5fbfeb98) at 
/Users/dsp/dev/c/php/trunk/sapi/cli/php_cli.c:1200

Test script:
---------------
<?php

$pdo = new PDO('mysql:dbname=mysql;host=127.0.0.1', 'root', '');
$stm = $pdo->prepare('SELECT * FROM user WHERE host = ?');
$stm->execute(array('localhost'));
$stm->fetchAll();

Actual result:
--------------
php(63324) malloc: *** error for object 0x101c849a8: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
[1]    63324 abort      php test.php

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-05-20 13:42 UTC] mike@php.net
-Status: Open +Status: Feedback
 [2010-05-20 13:42 UTC] mike@php.net
Please try using this snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:

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


 [2010-05-20 13:43 UTC] mike@php.net
erm, this should have been http://snaps.php.net/php-trunk-latest.tar.gz
 [2010-05-20 13:46 UTC] dsp@php.net
Sorry I forgot to add my configure:

'./configure' \
'--with-mysql=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
 [2010-05-20 22:00 UTC] dsp@php.net
-Status: Feedback +Status: Open
 [2010-05-21 09:21 UTC] dsp@php.net
Hunting down the bug it seems that 

mysqlnd.collect_memory_statistics = On

causes troubles.
 [2010-05-21 13:09 UTC] andrey@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=299574
Log: Fix for Bug #51870
PDO::fetchAll after a PDO::execute with bindings lead to a segv.

It is only in unreleased code and thus doesn't deserve a NEWS entry
 [2010-05-21 13:09 UTC] andrey@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: mysql
 [2010-05-21 13:09 UTC] andrey@php.net
Fixed in SVN, thank you for your report!
 [2010-05-21 19:47 UTC] dave at hobodave dot com
This still exists in the latest snapshot php5.3-201005211630.tar.gz

Test
----
<?php

$pdo = new PDO('mysql:dbname=test;host=localhost', 'root', '');
$stm = $pdo->prepare('SHOW FULL TABLES');
$stm->execute();
$stm->fetchAll();
 [2010-05-21 19:55 UTC] dave at hobodave dot com
#0  0x00007fff82410886 in __kill ()
#1  0x00007fff824b0eae in abort ()
#2  0x00007fff823c8a75 in free ()
#3  0x00000001020eefc5 in pdo_mysql_stmt_fetch ()
#4  0x000000010008bffe in do_fetch_common ()
#5  0x000000010008c107 in do_fetch ()
#6  0x000000010008e3bf in zim_PDOStatement_fetchAll ()
#7  0x000000010020359a in zend_do_fcall_common_helper_SPEC ()
#8  0x00000001001ff93b in execute ()
#9  0x00000001001db29b in zend_execute_scripts ()
#10 0x0000000100183d62 in php_execute_script ()
#11 0x000000010026c985 in main ()
 [2010-05-21 20:12 UTC] johannes@php.net
-Status: Closed +Status: Assigned
 [2010-05-21 20:12 UTC] johannes@php.net
re-open after comment from dave.
 [2010-05-21 21:28 UTC] dave at hobodave dot com
Please disregard my previous comments. My environment was screwed, and an old 
pdo_mysql version was being loaded dynamically.
 [2010-05-25 10:46 UTC] uw@php.net
-Status: Assigned +Status: Closed
 [2010-05-25 10:46 UTC] uw@php.net
As Dave says, its been his env fooling him
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 11:01:29 2024 UTC