Question

我正在开发通过ODBC（unixodbc）使用DB2数据库的软件。问题是运行带有valgrind的测试套件会产生大量错误。更不用说连接和断开连接会产生4k错误消息（下面提供的代码）。我的问题是：

我是否在连接和断开连接时出错？
是否有通过libdb2释放已分配内存的清理功能？
Valgrind还有消息抑制功能，是否存在libdb2.so库的压缩文件？

代码：

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;
}

我正在使用：

libdb2.so从Linux 64bit的DSClients-linuxx64-odbc_cli-10.1.0.2-FP002软件包中获取。
libodbc.so版本2.3.1

修改

最后的valgrind消息（bigest漏洞）：

==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)

大多数泄漏都是静态的（初始化）。每个连接断开连接都会增加80字节，以确保丢失字节数。

valgrind输出的一小部分（无法粘贴超过500k）：http://pastebin.com/xZfjy21Q

最大的问题是我无法找到由我的行为引起的问题。

修改

双重检查二进制文件，都是64位。

DB2通过ODBC内存管理问题

0 个答案: