ID: 35332
User updated by: joh at deworks dot net
Reported By: joh at deworks dot net
Status: Closed
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-11-22 (snap)
Assigned To: wez
New Comment:
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!
Previous Comments:
------------------------------------------------------------------------
[2005-11-25 01:33:18] [EMAIL PROTECTED]
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-22 22:32:29] [EMAIL PROTECTED]
Assigned to the maintainer.
------------------------------------------------------------------------
[2005-11-22 15:48:10] joh at deworks dot net
Actually, the same thing happens when doing:
$statement->execute(array('name' => 'date', 'data' => 'Foo!'));
------------------------------------------------------------------------
[2005-11-22 15:45:21] 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
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=35332&edit=1
