|
Problem IC72649
|
Status: Closed |
MEMORY LEAK WHEN RUNNING CLI/ODBC APPLICATION THAT ALLOCATES AND FREES AN ENVIRONMENT HANDLE FOR EVERY ITERATION IN THE PROCESS. |
| product: |
DB2 CONNECT / DB2CONNCT / 970 - DB2 |
| Problem description: |
A CLI / ODBC application can have a memory leak if the
application makes the following series of calls in a loop:
SQLAllocHandle (SQL_HANDLE_ENV)
SQLAllocHandle (SQL_HANDLE_DBC)
SQLConnect()
SQLDisconnect()
SQLFreeHandle (SQL_HANDLE_DBC)
SQLFreeHandle (SQL_HANDLE_ENV)
This can also occur if the application process spawns threads
that perform those sequence of calls and multiple threads are
invoked.
This memory leak will only occur when the db2app.dll library is
being unloaded and reloaded. When using the DB2 CLI/ODBC driver
with Microsoft's ODBC driver manager, the memory leak will occur
since the ODBC driver unloads db2app.dll when SQLFreeHandle
(SQL_HANDLE_ENV) is called. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Windows only. *
****************************************************************
* PROBLEM DESCRIPTION: *
* A CLI / ODBC application can have a memory leak if the *
* application makes the following series of calls in a loop: *
* *
* SQLAllocHandle (SQL_HANDLE_ENV) *
* SQLAllocHandle (SQL_HANDLE_DBC) *
* SQLConnect() *
* SQLDisconnect() *
* SQLFreeHandle (SQL_HANDLE_DBC) *
* SQLFreeHandle (SQL_HANDLE_ENV) *
* *
* *
* This can also occur if the application process spawns *
* threads that perform those sequence of calls and multiple *
* threads are invoked. *
* *
* This memory leak will only occur when the db2app.dll library *
* is being unloaded and reloaded. When using the DB2 CLI/ODBC *
* driver with Microsoft's ODBC driver manager, the memory leak *
* will occur since the ODBC driver unloads db2app.dll when *
* SQLFreeHandle (SQL_HANDLE_ENV) is called. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 v9.7, Fixpak 4 *
**************************************************************** |
| Local Fix: |
Instead of allocating a new environment handle for each
iteration, just use one environment handle. Then allocate a new
connection handle for each iteration from that environment
handle. If using threads, allocate the environment handle in
the main thread, and allocate the connection handles in the
child thread. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Problem was first fixed in Version 9.7 Fix Pack 4 |
| Workaround |
Instead of allocating a new environment handle for each
iteration, just use one environment handle. Then allocate a
new connection handle for each iteration from that environment
handle. If using threads, allocate the environment handle in
the main thread, and allocate the connection handles in the
child thread. |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 17.11.2010
02.05.2011
02.05.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.,
9.7.FP4
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.4
|
 |
