常在河边走，终于碰上了严重的内存泄漏。。。

在此记录下，也提醒其他常在河边走的c/c++童鞋
服务端数据库接口，长连接数据库，客户端并发操作（查询）超过60多个并发就会报如下错误
in UnionCheckError:: --- db2 error report begin ---
20110402105607::[UserErr][5030014][-10009]
SQLSTATE: 57011
20110402105607::[UserErr][5030014][-10009]
NATIVE: -954
20110402105607::[UserErr][5030014][-10009]
MESSAGE: [IBM][CLI Driver][DB2/AIX64] SQL0954C   Not enough storage is available in the application heap to process the statement.   SQLSTATE=57011
20110402105607::[UserErr][5030014][-10009]
in UnionCheckError:: --- db2 error report End ---
google后说是DB2数据库设置的应用程序堆太小
$ db2 get db cfg for cmbkmcdb | grep APPLHEAPSZ
Default application heap (4KB)          (APPLHEAPSZ) = 256
APPLHEAPSZ为256，
$ db2 update db cfg for CMBKMCDB using APPLHEAPSZ 4096
改成4096后仍同样错误。
之前的接口使用DB2 ESQL写的，由于要bind，客户觉得麻烦让我们改成CLI的，服务端结构应该没什么问题，原来ESQL的接口我们测时服务端能承受几千并发也不会报SQL0954C SQLSTATE=57011
最初没有怀疑是内存泄漏，因为种种迹象都表明是数据库问题。
这个问题很可恶，造成服务端无法操作数据库提供服务，而且服务端程序也没有core 。。。
然后一点点小量的测试，无意中看了下程序的内存占用，才发现每测试一次内存占用就涨一点，这才缓然大悟。。。然后从上午开始手工检查代码（因为AIX上似乎没有顺手的检查内存泄漏的工具，valgrind要依赖一大堆东西没有时间折腾。。。）
。。。
。。。
。。。
最终在
int UnionFreeStmtHandle()
{
    //SQLFreeHandle(SQL_HANDLE_STMT, stmt_handle);
    if (SQL_NULL_HSTMT == stmt_handle || SQL_NULL_HSTMT == stmt_handle1)
        return 0;
    ……
    在此执行真正的释放动作
    ……
}
UnionFreeStmtHandle是释放stmt_handle的并不是释放stmt_handle1的，释放stmt_handle的时候stmt_handle1一般都是SQL_NULL_HSTMT，然后没有释放stmt_handle就return 0;，从此爆发。。。