DB2 via ODBC memory management issues - c

Question

I'm developing software that uses DB2 database via ODBC (unixodbc). The issue is that running test suite with valgrind produces massive amount of errors. Let alone one connect and disconnect generates 4k error messages (code provided below). My question is:
Am I doing something wrong with connect and disconnect?
Is there clean up function that frees allocated memory by libdb2?
Valgrind also has message suppression feature, is there maintained suppression file for libdb2.so library?
Code:
static void
connect_disconnect(SQLCHAR *dsn)
{
SQLRETURN ret = -1;
SQLHENV env = NULL;
SQLHDBC dbc = NULL;
SQLCHAR msg[1024];
SQLSMALLINT msglen = 0;
/* env handle */
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env);
SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0);
/* connection */
SQLAllocHandle(SQL_HANDLE_DBC, env, &dbc);
ret = SQLDriverConnect(dbc, NULL, (SQLCHAR *)dsn,
SQL_NTS, msg, sizeof(msg), &msglen, SQL_DRIVER_COMPLETE);
if (!SQL_SUCCEEDED(ret))
{
fprintf(stderr, "Failed to connect to database '%s'.\n", dsn);
extract_error(dbc, SQL_HANDLE_DBC);
}
SQLDisconnect(dbc);
SQLFreeHandle(SQL_HANDLE_DBC, dbc);
dbc = NULL;
SQLFreeHandle(SQL_HANDLE_ENV, env);
env = NULL;
return;
}
I'm using:
libdb2.so acquired from DSClients-linuxx64-odbc_cli-10.1.0.2-FP002 package for Linux 64bit.
libodbc.so version 2.3.1
Edit
Last valgrind message (bigest leak):
==1318== 425,880 bytes in 1 blocks are possibly lost in loss record 145 of 145
==1318== at 0x4C2C04B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1318== by 0x68B313D: _ossMemAlloc (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6A3B513: sqlnlscmsg(char const*, SQLNLS_MSG_FILE_HEADER**, char const*, bool*, char*) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6A3AC90: sqlnlsMessage (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6A3A589: sqlnlsMessage (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6C43128: sqloMessage (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6BDCDE0: sqllcGetMessage(char const*, int, char*, char*, unsigned long, bool, char const*) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6BE0F79: sqllcInitComponent(unsigned int) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6BE14E2: sqllcInitData() (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6BD813C: sqllcGetInstalledKeyType (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6C26653: sqloGetInstalledKeyType (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6B42494: sqleuInvokeActivationRoutine(db2UCconHandle*, SQLEU_UDFSP_ARGS*, sqlca*, bool, unsigned int) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6B413A3: sqleuPerformServerActivationCheck(db2UCconHandle*, sqlca*) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x6B3FF72: sqleUCappConnect (in /usr/local/lib/libdb2.so.1)
==1318== by 0x69E8F9A: CLI_sqlConnect(CLI_CONNECTINFO*, sqlca*, CLI_ERRORHEADERINFO*) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x699997D: SQLConnect2(CLI_CONNECTINFO*, unsigned char*, short, unsigned char*, short, unsigned char*, short, unsigned char*, short, unsigned char) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x69B2640: SQLDriverConnect2(CLI_CONNECTINFO*, void*, unsigned char*, short, unsigned char*, short, short*, unsigned short, unsigned char, unsigned char, CLI_ERRORHEADERINFO*) (in /usr/local/lib/libdb2.so.1)
==1318== by 0x698BD4E: SQLDriverConnect (in /usr/local/lib/libdb2.so.1)
==1318== by 0x4E45962: SQLDriverConnect (in /usr/lib/libodbc.so.2.0.0)
==1318== by 0x400BF2: connect_disconnect (in /.../db2_leak/test)
==1318== by 0x400A8F: main (in /.../db2_leak/test)
Most of leaks are static (initialization). Each connect disconnect adds 80bytes to definitely lost byte count.
A bit bigger part of valgrind output (could not paste more then 500k): http://pastebin.com/xZfjy21Q
Biggest issue is that I cant find issues caused by my actions.
Edit
Double checked binaries, all are 64bit.