[2004-05-29 18:37 UTC] novicky at aarongroup dot cz

Description:
------------
Identification strings used for connections, statements and descriptors are not thread safe. There is a possible mix-up of identifications under multithread webservers.

There is a possible memory allocation during module shutdown in function ifx_do_close which can lead crash.

Here is a patch for ifx.ec

--- php-4.3.7RC1.orig/ext/informix/ifx.ec	2003-11-03 00:14:06.000000000 +0100
+++ php-4.3.7RC1/ext/informix/ifx.ec	2004-05-29 18:14:16.000000000 +0200
@@ -297,30 +297,13 @@
 			if (ifx_check() == 0)   {
 				/* DISCONNECT again, after rollback */
 				EXEC SQL DISCONNECT :link;
-				if (ifx_check() < 0)   {
-					IFXG(sv_sqlcode) = SQLCODE;
-					php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s after Automatic Rollback fails (%s)", link, ifx_error(link));
-				}
 			}
-			if (ifx_check() < 0)   {
+			else if (ifx_check() < 0)   {
 				/* CLOSE database if rollback or disconnect fails */
 				EXEC SQL CLOSE DATABASE;
-				if (ifx_check() < 0)   {
-					IFXG(sv_sqlcode) = SQLCODE;
-					php_error_docref(NULL TSRMLS_CC, E_WARNING, "Close database fails %s (%s)", link, ifx_error(link));
-				}
-			}
-		}
-		else if (SQLCODE < 0)   {
-			IFXG(sv_sqlcode) = SQLCODE;
-			php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s fails (%s)", link, ifx_error(link));
 		}
 	}       
-	else   {
-		IFXG(sv_sqlcode) = SQLCODE;
-		php_error_docref(NULL TSRMLS_CC, E_WARNING, "Set connection %s fails (%s)", link, ifx_error(link));
 	}
-
 }
 
 static void _close_ifx_link(zend_rsrc_list_entry *rsrc TSRMLS_DC)
@@ -532,7 +515,11 @@
 			/* create the link */
 			ifx = (char *) malloc(sizeof(IFX));
 			IFXG(connectionid)++;
+#ifdef ZTS
+			sprintf(ifx, "%s%x_%x", SAFE_STRING(user), tsrm_thread_id(), IFXG(connectionid));
+#else
 			sprintf(ifx, "%s%x", SAFE_STRING(user), IFXG(connectionid));
+#endif
 			
 			EXEC SQL CONNECT TO :host AS :ifx USER :user USING :passwd WITH CONCURRENT TRANSACTION;  
 	
@@ -629,7 +616,11 @@
 
 		ifx = (char *) emalloc(sizeof(IFX));
 		IFXG(connectionid)++;
+#ifdef ZTS
+		sprintf(ifx, "connec%x_%x", tsrm_thread_id(), IFXG(connectionid));
+#else
 		sprintf(ifx, "connec%x", IFXG(connectionid));
+#endif
 		
 		EXEC SQL CONNECT TO :host AS :ifx USER :user USING :passwd WITH CONCURRENT TRANSACTION;
 
@@ -800,10 +791,17 @@
 	statement = Z_STRVAL_PP(query);
 
 	IFXG(cursorid)++;
+#ifdef ZTS
+	sprintf(statemid, "statem%x_%x", tsrm_thread_id(), IFXG(cursorid)); 
+	sprintf(cursorid, "cursor%x_%x", tsrm_thread_id(), IFXG(cursorid)); 
+	sprintf(descrpid, "descrp%x_%x", tsrm_thread_id(), IFXG(cursorid)); 
+	sprintf(i_descrpid, "i_descrp%x_%x", tsrm_thread_id(), IFXG(cursorid));
+#else
 	sprintf(statemid, "statem%x", IFXG(cursorid)); 
 	sprintf(cursorid, "cursor%x", IFXG(cursorid)); 
 	sprintf(descrpid, "descrp%x", IFXG(cursorid)); 
 	sprintf(i_descrpid, "i_descrp%x", IFXG(cursorid));
+#endif
 
 	EXEC SQL set connection :ifx;
 	PHP_IFX_CHECK_CONNECTION(ifx);
@@ -1206,10 +1204,17 @@
 	statement = Z_STRVAL_PP(query);
 
 	IFXG(cursorid)++;
+#ifdef ZTS
+	sprintf(statemid, "statem%x_%x", tsrm_thread_id(), IFXG(cursorid)); 
+	sprintf(cursorid, "cursor%x_%x", tsrm_thread_id(), IFXG(cursorid)); 
+	sprintf(descrpid, "descrp%x_%x", tsrm_thread_id(), IFXG(cursorid)); 
+	sprintf(i_descrpid, "i_descrp%x_%x", tsrm_thread_id(), IFXG(cursorid));
+#else
 	sprintf(statemid, "statem%x", IFXG(cursorid)); 
 	sprintf(cursorid, "cursor%x", IFXG(cursorid)); 
 	sprintf(descrpid, "descrp%x", IFXG(cursorid)); 
 	sprintf(i_descrpid, "i_descrp%x", IFXG(cursorid));
+#endif
 
 	EXEC SQL set connection :ifx;
 	PHP_IFX_CHECK_CONNECTION(ifx);




Moreover there is a memory leak in all php_error_docref calls where ifx_error(ifx) is used. There are 64 bytes allocated which are never free.

 [2004-06-01 03:08 UTC] abies@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.