php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49937 [PATCH] Race condition in PDOStatement
Submitted: 2009-10-20 22:43 UTC Modified: 2013-02-18 00:34 UTC
Votes:6
Avg. Score:5.0 ± 0.0
Reproduced:5 of 6 (83.3%)
Same Version:0 (0.0%)
Same OS:1 (20.0%)
From: basantk@php.net Assigned: basantk (profile)
Status: No Feedback Package: PDO related
PHP Version: 5.2.11 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: basantk@php.net
New email:
PHP Version: OS:

 

 [2009-10-20 22:43 UTC] basantk@php.net
Description:
------------
There is a race condition in pdo's stmt PDOStatement class.
This class is dynamically created and it adds a member named queryString
(inside pdo_stmt_init).
zend_declare_property_null allocates property using malloc.

Later pdo_dbstmt_ce is copied to other hashes in pdo_dbstmt_new.
zend_hash_copy increments refcount of pdo_dbstmt_ce->queryString property. In
multithreaded php refcount increment was not atomic. It was causing refcount
to become 0 and hence efree was trying to delete something which was allocated
from malloc.



There is a php benchmark kit named olio and can be downloaded from :
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=Olio-PHP-1.0-A-G-F@CDS-CDS_SMI

The bug is easily reproducible with olio php benchmark inside Sun Web Server.


Expected result:
----------------
Correct functionality

Actual result:
--------------
Stack trace :
--------------
Program terminated with signal 11, Segmentation fault.
#0  0x00002ba1630451e0 in _zend_mm_free_int ()
  from /home/sun/webserver7/bin/libphp5.so
#1  0x00002ba163084aa0 in zend_std_write_property ()
  from /home/sun/webserver7/bin/libphp5.so
#2  0x00002ba162ebfc4a in pdo_stmt_construct ()
  from /home/sun/webserver7/bin/libphp5.so
#3  0x00002ba162ec0073 in zim_PDO_query ()
  from /home/sun/webserver7/bin/libphp5.so
#4  0x00002ba1630999f9 in zend_do_fcall_common_helper_SPEC ()
  from /home/sun/webserver7/bin/libphp5.so
#5  0x00002ba16308705f in execute () from /home/sun/webserver7/bin/libphp5.so
#6  0x00002ba1630993d8 in zend_do_fcall_common_helper_SPEC ()
  from /home/sun/webserver7/bin/libphp5.so
#7  0x00002ba16308705f in execute () from /home/sun/webserver7/bin/libphp5.so
#8  0x00002ba1630630fa in zend_execute_scripts ()
  from /home/sun/webserver7/bin/libphp5.so
#9  0x00002ba1630188bb in php_execute_script ()
  from /home/sun/webserver7/bin/libphp5.so
#10 0x00002ba1630ee465 in php5_execute ()



Patches

pdo_race_condition_fix_53.patch (last revision 2010-09-22 23:11 UTC by basantk@php.net)
pdo_race_condition_fix (last revision 2010-08-25 00:13 UTC by basantk@php.net)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-20 22:45 UTC] basantk@php.net
Here is the patch which fixes the race condition in pdo :
Patch is generated against PHP_5_2 svn branch.

Index: ext/pdo/pdo_stmt.c
===================================================================
--- ext/pdo/pdo_stmt.c	(revision 289806)
+++ ext/pdo/pdo_stmt.c	(working copy)
@@ -2325,7 +2325,7 @@
 	stmt->refcount = 1;
 	ALLOC_HASHTABLE(stmt->properties);
 	zend_hash_init(stmt->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
-	zend_hash_copy(stmt->properties, &stmt->ce->default_properties, (copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
+	zend_hash_copy(stmt->properties, &stmt->ce->default_properties, (copy_ctor_func_t) zval_add_ref_atomic, (void *) &tmp, sizeof(zval *));
 
 	old_stmt = (pdo_stmt_t *)zend_object_store_get_object(zobject TSRMLS_CC);
 	
@@ -2454,7 +2454,7 @@
 	stmt->refcount = 1;
 	ALLOC_HASHTABLE(stmt->properties);
 	zend_hash_init(stmt->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
-	zend_hash_copy(stmt->properties, &ce->default_properties, (copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
+	zend_hash_copy(stmt->properties, &ce->default_properties, (copy_ctor_func_t) zval_add_ref_atomic, (void *) &tmp, sizeof(zval *));
 
 	retval.handle = zend_objects_store_put(stmt, (zend_objects_store_dtor_t)zend_objects_destroy_object, (zend_objects_free_object_storage_t)pdo_dbstmt_free_storage, (zend_objects_store_clone_t)dbstmt_clone_obj TSRMLS_CC);
 	retval.handlers = &pdo_dbstmt_object_handlers;
Index: TSRM/TSRM.c
===================================================================
--- TSRM/TSRM.c	(revision 289806)
+++ TSRM/TSRM.c	(working copy)
@@ -714,6 +714,12 @@
 	return retval;
 }
 
+TSRM_API void *tsrm_atomic_incr(volatile unsigned int* val)
+{
+	tsrm_mutex_lock(tsmm_mutex);
+	++*val;
+	tsrm_mutex_unlock(tsmm_mutex);
+}
 
 
 /*
Index: TSRM/TSRM.h
===================================================================
--- TSRM/TSRM.h	(revision 289806)
+++ TSRM/TSRM.h	(working copy)
@@ -139,6 +139,7 @@
 
 TSRM_API void *tsrm_set_new_thread_begin_handler(tsrm_thread_begin_func_t new_thread_begin_handler);
 TSRM_API void *tsrm_set_new_thread_end_handler(tsrm_thread_end_func_t new_thread_end_handler);
+TSRM_API void *tsrm_atomic_incr(volatile unsigned int* val);
 
 /* these 3 APIs should only be used by people that fully understand the threading model
  * used by PHP/Zend and the selected SAPI. */
Index: Zend/zend_variables.c
===================================================================
--- Zend/zend_variables.c	(revision 289806)
+++ Zend/zend_variables.c	(working copy)
@@ -100,6 +100,17 @@
 }
 /* }}} */
 
+
+ZEND_API void zval_add_ref_atomic(zval **p) /* {{{ */
+{
+#ifdef ZTS
+	tsrm_atomic_incr(&(*p)->refcount);
+#else
+	(*p)->refcount++;
+#endif
+}
+/* }}} */
+
 ZEND_API void _zval_copy_ctor_func(zval *zvalue ZEND_FILE_LINE_DC) /* {{{ */
 {
 	switch (zvalue->type) {
Index: Zend/zend_variables.h
===================================================================
--- Zend/zend_variables.h	(revision 289806)
+++ Zend/zend_variables.h	(working copy)
@@ -76,6 +76,7 @@
 #endif
 
 ZEND_API void zval_add_ref(zval **p);
+ZEND_API void zval_add_ref_atomic(zval **p);
 
 END_EXTERN_C()
 

 [2009-10-21 21:06 UTC] basantk@php.net
More explaination about the problem :

Php class PDOStatement is created inside pdo_stmt_init.  A property named
"queryString" is inserted to the properties table (zend_hash) using
zend_declare_property_null.

	INIT_CLASS_ENTRY(ce, "PDOStatement", pdo_dbstmt_functions);
	pdo_dbstmt_ce = zend_register_internal_class(&ce TSRMLS_CC);
	pdo_dbstmt_ce->get_iterator = pdo_stmt_iter_get;
	pdo_dbstmt_ce->create_object = pdo_dbstmt_new;
	zend_class_implements(pdo_dbstmt_ce TSRMLS_CC, 1, zend_ce_traversable); 
	zend_declare_property_null(pdo_dbstmt_ce, "queryString", sizeof("queryString")-1, ZEND_ACC_PUBLIC TSRMLS_CC);


zend_declare_property_null allocates a null zval using malloc for
"queryString" property.

int zend_declare_property_null(...) {
	zval *property;
	if (ce->type & ZEND_INTERNAL_CLASS) {
		property = malloc(sizeof(zval));
	} else {
...
}

Now pdoStatement->ce->default_properties{"queryString"} is a null zval object
created by "malloc". Let me call this zval object zPdoStmtQstrProp for
explaination.

Now notice the function call in dbstmt_clone_obj or pdo_dbstmt_new :
	zend_hash_copy(stmt->properties, &stmt->ce->default_properties, (copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));

When PDOStatement is cloned, it copies the stmt->ce->default_properties to the
new statement using zend_hash_copy. zend_hash_copy will call
zPdoStmtQstrProp->ref_count++ by calling zval_add_ref.

This is what is thread-unsafe. zPdoStmtQstrProp is a global object whose
reference count is incremented without any kind of lock. Under stress
situation since ref count becomes 0 and efree tries to invoke for a object
which is created using malloc.

--------------------------------------------------------------
Where does decrement happens :
-------------------------
gdb) where
#0  _zval_ptr_dtor (zval_ptr=0x4d7fa10) at ../PHP_5_2/Zend/zend_execute_API.c:413
#1  0x015cf4cb in zend_std_write_property (object=0xb7718ad8, member=0x4d7faa4, value=0xb7718c90,
    tsrm_ls=0xb77087e8) at ../PHP_5_2/Zend/zend_object_handlers.c:417
#2  0x013dfb76 in pdo_stmt_construct (stmt=0xb7718b48, object=0xb7718ad8, dbstmt_ce=0x9d0f0c8, ctor_args=0x0,
    tsrm_ls=0xb77087e8) at ../PHP_5_2/ext/pdo/pdo_dbh.c:446

This is the place where we see the crash. As the object was allocated using
malloc and _zval_ptr_dtor tries to free the object using efree.

--------------------------------------------------------------

Regarding submitted fix :

Now regarding the fix which I submitted though seems to solve the problem but
the fix still doesn't address  the issue completely because it doesn't ensure
the atomicity of the decrement call. A new fix is required which ensure the
thread safety of zPdoStmtQstrProp->refcount.

 [2009-10-23 18:15 UTC] basantk@php.net
Here is a revised patch which is much less invasive, restricts totally to pdo.
Fix is to avoid using shared zval ptr
(PdoStatement->ce->propertiers{"queryString"}) in multiple PdoStatement
objects.  Instead it creates a copy of the "null" zval for individual object.

This fix the race condition for me and have been verified by one of the olio
php customer.  I ran the pdo_sqlite tests and didn't find any regression.

Here is the fix
---------------------------------------------

Index: ext/pdo/pdo_stmt.c
===================================================================
--- ext/pdo/pdo_stmt.c	(revision 289806)
+++ ext/pdo/pdo_stmt.c	(working copy)
@@ -2312,6 +2312,54 @@
 	return -1;
 }
 
+static void init_stmt_properties(pdo_stmt_t* stmt TSRMLS_DC)
+{
+	HashTable* ht =  &stmt->ce->default_properties;
+	HashTable* target = stmt->properties;
+
+	HashPosition pos;
+	zend_hash_internal_pointer_reset_ex(ht, &pos);
+	while(zend_hash_has_more_elements_ex(ht, &pos)
+			   	== SUCCESS) {
+		ulong index;
+		char* key = NULL;
+		uint keylen = 0;
+		int ret = zend_hash_get_current_key_ex(ht,
+											   &key,
+											   &keylen,
+											   &index, 0,
+											   &pos);
+		if ((keylen == sizeof("queryString"))
+				&& (strncmp(key, "queryString", keylen) == 0)) {
+			zval* qval;
+			/* Since the value for the key queryString in
+			 * stmt->ce->default_properties is shared by multiple threads so
+			 * we can not add the same zval in stmt->properties. we need to
+			 * create a null property object. See Bug 49937 */
+			ALLOC_INIT_ZVAL(qval);
+			zend_hash_add(stmt->properties, "queryString", 
+						  sizeof("queryString"), (void**) &qval, sizeof(zval*), NULL);
+		}
+		else {
+			void* data = NULL;
+			zend_hash_get_current_data_ex(ht,
+										  (void **) &data, &pos);
+			void *new_entry = NULL;
+			if (data) {
+				/* We expect keylen should be > 0. default_properties hash
+				 * should only contain named keys */
+				if (keylen) {
+					zend_hash_quick_update(target, key, keylen, 0, data, sizeof(void*), &new_entry);
+				} 
+				if (new_entry) {
+					zval_add_ref(new_entry);
+				}
+			}
+		}
+		zend_hash_move_forward_ex(ht, &pos);
+	}
+}
+
 static zend_object_value dbstmt_clone_obj(zval *zobject TSRMLS_DC)
 {
 	zend_object_value retval;
@@ -2325,7 +2373,7 @@
 	stmt->refcount = 1;
 	ALLOC_HASHTABLE(stmt->properties);
 	zend_hash_init(stmt->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
-	zend_hash_copy(stmt->properties, &stmt->ce->default_properties, (copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
+	init_stmt_properties(stmt TSRMLS_CC);
 
 	old_stmt = (pdo_stmt_t *)zend_object_store_get_object(zobject TSRMLS_CC);
 	
@@ -2454,7 +2502,7 @@
 	stmt->refcount = 1;
 	ALLOC_HASHTABLE(stmt->properties);
 	zend_hash_init(stmt->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
-	zend_hash_copy(stmt->properties, &ce->default_properties, (copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
+	init_stmt_properties(stmt TSRMLS_CC);
 
 	retval.handle = zend_objects_store_put(stmt, (zend_objects_store_dtor_t)zend_objects_destroy_object, (zend_objects_free_object_storage_t)pdo_dbstmt_free_storage, (zend_objects_store_clone_t)dbstmt_clone_obj TSRMLS_CC);
 	retval.handlers = &pdo_dbstmt_object_handlers;

 [2009-11-17 02:51 UTC] basantk@php.net
Here is the link to the patch which I submitted in previous
comments. 
http://bitbucket.org/basantk/phpbugs/raw/5c3ca3a306ed/pdo_bug_52trunk.txt

Marking the bug as Patch available.
 [2010-03-09 01:23 UTC] felipe@php.net
-Status: Open +Status: Assigned
 [2010-07-13 09:57 UTC] kkaminski at itens dot pl
Any chances of getting this patch into PHP 5.2.14? Or getting a windows build for testing?
I'd like to give it a try but having problems building PHP under winblows :/
 [2010-08-23 12:30 UTC] kkaminski at itens dot pl
Tested patch and it works, but now I'm having similar problem.
Apache is crashing in
pdo_stmt_construct
on
std_object_handlers.write_property(object, &z_key, query_string TSRMLS_CC);

Could you please verify this?
 [2010-08-23 13:50 UTC] pajoye@php.net
I'm not sure the fix is correct (while it can work). It should be done inside zend_hash_copy instead of adding a zval_add_ref_atomic. Or?

zval_ref_atomic could be added but then I would rather not use the expensive TSRM locking system but atomic declarations and the OS specific atomic APIs.
 [2010-08-24 18:45 UTC] basantk@php.net
pajoye, my first patch was a rough patch which used zval_add_ref_atomic.

Second patch posted on 2009-11-17 is my final patch. This patch doesn't need
any enhancement to php core and it worked for me and several others without 
crashes. I had tested with iplanet web server on Solaris and Linux and I believe 
it will work with other multithreaded web servers.

Please review the patch posted on 2009-11-17,

kkaminski, which patch did you tested. You should test the revised patch 
submitted on 2009-11-17. Please post the stack trace of the crash if you tested 
the right patch.

Unfortunately php's bug tracker is very primitive in terms of feature. Apache's 
bug tracker is lot better :-)
 [2010-08-24 19:24 UTC] pajoye@php.net
Can you attach the patch to the report please? Much more easier to follow/review :)
 [2010-08-24 19:38 UTC] kkaminski at itens dot pl
basantk: I used the patch you published in pdo_bug_52trunk.txt (this is complete
patch, riight?). The patch fixed
my original problem but introduced a new one - in
pdo's constructor. As far I understood the code it is something with memory
(de)allocation for queryString property.
I don't have access to crash dumps at the moment, but I will provide full stack
trace tomorrow.
 [2010-08-24 20:17 UTC] basantk@php.net
pajoye, patch is already there in bug log. Look at the patch submitted at  2009-
10-23 16:15 UTC. Http link to the same patch has been provided in comments posted
at 2009-11-17 01:51 UTC. I posted the http link of the patch because it makes it 
easier to commit.

(Unfortunately bug database don't have easy way to refer to comments #).
 [2010-08-24 20:31 UTC] pajoye@php.net
Please >attach< the patch to this report, upload it if you prefer. There is a upload field for this exact purpose. Comments are for comments, not for patches (which may loose their text format).
 [2010-08-25 02:13 UTC] basantk@php.net
The following patch has been added/updated:

Patch Name: pdo_race_condition_fix
Revision:   1282695197
URL:        http://bugs.php.net/patch-display.php?bug=49937&patch=pdo_race_condition_fix&revision=1282695197
 [2010-08-25 02:16 UTC] basantk@php.net
Sorry pajoye, I didn't know that there was a "patch upload" feature in bug database. I somehow missed the link in webpage.

Anyway, I have attached the patch now. Thanks.
 [2010-08-25 08:27 UTC] kkaminski at itens dot pl
basantk: As promised call stack (Visual Studio 2010) for my new problem below:
	php5ts.dll!_zend_mm_free_int(_zend_mm_heap * heap, void * p)  Line 1979 + 0x84 bytes	C
 	php5ts.dll!_efree(void * ptr)  Line 2311 + 0xb bytes	C
 	php5ts.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr)  Line 415 + 0x25 bytes	C
 	php5ts.dll!zend_std_write_property(_zval_struct * object, _zval_struct * member, _zval_struct * value, void * * * tsrm_ls)  Line 417 + 0xc bytes	C
 	php_pdo.dll!pdo_stmt_construct(_pdo_stmt_t * stmt, _zval_struct * object, _zend_class_entry * dbstmt_ce, _zval_struct * ctor_args, void * * * tsrm_ls)  Line 447	C
 	php_pdo.dll!zim_PDO_prepare(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr, _zval_struct * this_ptr, int return_value_used, void * * * tsrm_ls)  Line 581 + 0x16 bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 200 + 0x3d bytes	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 235	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 235	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 235	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 235	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 235	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 235	C
 	php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 322 + 0x11 bytes	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 2106	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls)  Line 2106	C
 	php5ts.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)  Line 92 + 0xc bytes	C
 	php5ts.dll!zend_execute_scripts(int type, void * * * tsrm_ls, _zval_struct * * retval, int file_count, ...)  Line 1135	C
 	php5ts.dll!php_execute_script(_zend_file_handle * primary_file, void * * * tsrm_ls)  Line 2036 + 0x12 bytes	C
 	php5apache2_2.dll!php_handler(request_rec * r)  Line 639 + 0xb bytes	C
 [2010-09-21 15:12 UTC] pajoye@php.net
-Status: Assigned +Status: Feedback
 [2010-09-21 15:12 UTC] pajoye@php.net
What's the status on this patch? Does it fix the issue shown in kkaminski at itens dot pl's last backtrace?

Does it apply to 5.3 as well? If yes, please provide against 5.3+.
 [2010-09-23 01:06 UTC] basantk@php.net
kkaminski, I am not sure if you have applied the patch and compiled correctly. I have not seen the crash after the fix. I had ran the benchmark test under stress for hours after this patch without any issue. Also it has been confirmed by one of the olio user.
 [2010-09-23 01:11 UTC] basantk@php.net
The following patch has been added/updated:

Patch Name: pdo_race_condition_fix_53.patch
Revision:   1285197073
URL:        http://bugs.php.net/patch-display.php?bug=49937&patch=pdo_race_condition_fix_53.patch&revision=1285197073
 [2010-09-23 08:34 UTC] kkaminski at itens dot pl
I confirm that basantk's patch fixes issue reported here.
But as I said before, I hit very similar problem in different place - PDOStatement::prepare. I think it is related to queryString written in prepare().

basantk: I have patched correctly PHP's source, your new function does not show up in crash dump, because prepare() does not use it.

Best regards
 [2010-09-28 08:12 UTC] basantk@php.net
kkaminski, I am not sure why it is crashing but it seems to me that crash is happening at the same place (pdo_stmt_construct). I can't help much unless I can reproduce it.
 [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-2024 The PHP Group
All rights reserved.
Last updated: Sun May 05 07:01:32 2024 UTC