libodbc++ 0.2.5创建数据库连接时内存泄漏问题求助

问题背景 #

使用libodbc++ 0.2.5版本循环创建销毁数据库连接时出现内存泄漏，示例代码如下：

while(1)
{
    Connection* con = DriverManager::getConnection(ConnectionString);
    if(con != NULL)
    {
        delete con;
        con = NULL;
    }
}

Valgrind日志显示泄漏来自iconv相关调用链：

==7534== 283,173,984 (1,074,640 direct, 282,099,344 indirect) bytes in 9,595 blocks are definitely lost in loss record 7,279 of 7,279 
==7534== at 0x4CE9B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==7534== by 0x6FEB3B7: __gconv_open (gconv_open.c:74) 
==7534== by 0x6FEB070: iconv_open (iconv_open.c:40) 
==7534== by 0x3172BEB: unicode_setup (__info.c:601) 
==7534== by 0x3136BD7: __SQLAllocHandle (SQLAllocHandle.c:492) 
==7534== by 0x310DC4F: odbc::DriverManager::_createConnection() (drivermanager.cpp:140) 
==7534== by 0x310DDBC: odbc::DriverManager::getConnection(...) (drivermanager.cpp:183) 

已确认SQLAllocHandle和SQLFreeHandle均被正确调用且返回SQL_SUCCESS，无连接泄漏，但内存未释放。

问题分析 #

从日志栈轨迹看，泄漏的内存来自iconv_open调用链，最终指向ODBC驱动的unicode_setup函数，而非libodbc的直接内存分配。结合你已验证的ODBC句柄调用逻辑，泄漏大概率是ODBC驱动本身的资源未释放，或是libodbc与新版系统组件（如glibc的iconv、unixODBC）存在兼容性问题。

解决建议 #

• 升级ODBC驱动：泄漏点位于驱动的unicode_setup逻辑中，优先尝试升级unixODBC到最新稳定版，老驱动的iconv资源泄漏问题在新版本中多已修复。
• 检查libodbc++连接销毁逻辑：虽然调用了delete con，需确认libodbc的Connection析构函数是否完整触发所有ODBC资源释放，比如是否遗漏SQLFreeEnv或其他驱动侧清理API。可通过查看libodbc源码（drivermanager.cpp、connection.cpp）或反编译确认析构逻辑。
• 使用连接池复用连接：避免频繁创建销毁连接，通过连接池减少资源申请次数，从根源缓解泄漏问题。可基于libodbc++封装简单连接池，或直接使用第三方ODBC连接池实现。
• 排查驱动unicode配置：部分ODBC驱动会缓存iconv转换句柄提升性能，可尝试修改驱动配置（如odbcinst.ini中的相关参数）禁用缓存，强制每次连接销毁时释放iconv资源。
• 替换libodbc++库：0.2.5版本距今已超过20年，项目早已停止维护，存在大量未修复的兼容性和稳定性问题。建议替换为活跃维护的ODBC C++封装库，或直接基于unixODBC的C API自行封装连接管理逻辑。

关于libodbc++的稳定性 #

libodbc++ 0.2.5属于老旧废弃项目，无后续维护更新，无法适配现代Linux系统的glibc、unixODBC等组件，在生产环境使用存在较高风险，包括内存泄漏、兼容性崩溃等问题，不建议用于长期运行的服务。

内容的提问来源于stack exchange，提问作者macla