php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35332 Segfault when using PDO: PGSQL and prepared statements with bindParam()
Submitted: 2005-11-22 15:45 UTC Modified: 2005-11-25 14:23 UTC
Votes:3
Avg. Score:4.7 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: joh at deworks dot net Assigned: wez (profile)
Status: Closed Package: PDO related
PHP Version: 5CVS-2005-11-22 (snap) OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: joh at deworks dot net
New email:
PHP Version: OS:

 

 [2005-11-22 15:45 UTC] joh at deworks dot net
Description:
------------
PHP segfaults when using PDO: PGSQL and prepared statements with bindParam() and execute().

Reproduce code:
---------------
$dsn = 'pgsql:...';
$user = '...';
$pass = '...';
$db = new PDO($dsn, $user, $pass);
$statement = $db->prepare("INSERT INTO testinggrounds (name, data) VALUES (:name, :data)");
$statement->execute(array('date', date('r')));
echo "First statement OK\n";
$statement->bindParam(':name', $name);
$statement->bindParam(':data', $data);
echo "Params bound to PHP variables\n";
// Insert a row
$name = 'date';
$data = 'test';
$statement->execute();
echo "Second statement OK\n";

Expected result:
----------------
First statement OK
Params bound to PHP variables
Second statement OK

Actual result:
--------------
First statement OK
Params bound to PHP variables
Segmentation fault

GDB backtrace:
(gdb) run
Starting program: /usr/local/bin/php PDO_dbg.php
[Thread debugging using libthread_db enabled]
[New Thread -1217852832 (LWP 19309)]
First statement OK
Params bound to PHP variables

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1217852832 (LWP 19309)]
0xb7d9f50a in pqHandleSendFailure () from /usr/lib/libpq.so.4
(gdb) bt
#0  0xb7d9f50a in pqHandleSendFailure () from /usr/lib/libpq.so.4
#1  0xb7da0091 in PQexecPrepared () from /usr/lib/libpq.so.4
#2  0x0813d505 in pgsql_stmt_execute (stmt=0x85b0104, tsrm_ls=0x8439018)
    at /shared/src/php/php5-200511221330/ext/pdo_pgsql/pgsql_statement.c:122
#3  0x0813704a in zif_PDOStatement_execute (ht=0, return_value=0x85b0604,
    return_value_ptr=0x0, this_ptr=0x85b3b6c, return_value_used=0,
    tsrm_ls=0x8439018)
    at /shared/src/php/php5-200511221330/ext/pdo/pdo_stmt.c:424
#4  0x082be11e in zend_do_fcall_common_helper_SPEC (execute_data=0xbfae2b6c,
    tsrm_ls=0x8439018) at zend_vm_execute.h:188
#5  0x082bd70a in execute (op_array=0x859524c, tsrm_ls=0x8439018)
    at zend_vm_execute.h:88
#6  0x08298a4e in zend_execute_scripts (type=8, tsrm_ls=0x8439018, retval=Variable "retval" is not available.
)
    at /shared/src/php/php5-200511221330/Zend/zend.c:1090
#7  0x0825affa in php_execute_script (primary_file=0xbfae4f6c,
    tsrm_ls=0x8439018) at /shared/src/php/php5-200511221330/main/main.c:1704
#8  0x08332977 in main (argc=2, argv=0xbfae5054)
    at /shared/src/php/php5-200511221330/sapi/cli/php_cli.c:1039
(gdb) bt full
#0  0xb7d9f50a in pqHandleSendFailure () from /usr/lib/libpq.so.4
No symbol table info available.
#1  0xb7da0091 in PQexecPrepared () from /usr/lib/libpq.so.4
No symbol table info available.
#2  0x0813d505 in pgsql_stmt_execute (stmt=0x85b0104, tsrm_ls=0x8439018)
    at /shared/src/php/php5-200511221330/ext/pdo_pgsql/pgsql_statement.c:122
        S = (pdo_pgsql_stmt *) 0x85b028c
        H = (pdo_pgsql_db_handle *) 0x859a06c
        status = Variable "status" is not available.
(gdb)

Thanks

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-22 15:48 UTC] joh at deworks dot net
Actually, the same thing happens when doing:

$statement->execute(array('name' => 'date', 'data' => 'Foo!'));
 [2005-11-22 22:32 UTC] tony2001@php.net
Assigned to the maintainer.
 [2005-11-25 01:33 UTC] wez@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fixed in CVS.
Try the next snapshot to confirm.

FYI, the problem stems from you binding parameters both by name and by position.  If you change your first execute call to this:

  $statement->execute(array(':name'=>'date',
     ':data'=>date('r')));

then PDO won't crash.

The fix in CVS allows your original script to run successfully, but you shouldn't rely on being able to mix binding by number and by name on the same statement; some drivers may report invalid parameter name or number when you do that.

 [2005-11-25 14:23 UTC] joh at deworks dot net
Ah, I see. I'll remember that.

Theoretically though, I really don't see why there should be a problem binding a parameter to more than one variable, regardless of how you bind it. Isn't the idea that the bound variables should act as references to the internal statement value? I.e.
$stmt = $db->prepare("SELECT * FROM foo WHERE bar=:bar");
$stmt->bindParam(1, $bar1);
$stmt->bindParam(":bar", $bar2);

$bar1 and $bar2 should now point to the same internal variable.

I don't know exactly how PDO does this internally, and I'm sure there's a reason why this isn't a good idea (how the RDBMS APIs with native support for statements handle this for example), but theoretically it should work that way, shouldn't it?

Anyways, I just tested with the latest snapshot, and it works perfectly!

Thank you, and keep up the good work!
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon Jan 24 00:03:35 2022 UTC