TXSeries内存泄露诊断一例

1.
前一段做过一次TXSeries内存泄露的诊断，有了诊断工具和实验室的支持，短短两天就定位了应用的类库原因。不过里面的工具需要正式的技术服务才能够获得。


2. Dumpbt工具的使用
2.1 Dumpbt原理
该脚本使得dbx绑定到指定region的所有cicsas进程。该脚本将获取所有在cmdfile(一般为malloc_common和free_common)的堆栈。
需要注意的是开启大量的dbx进程以及将dbx绑定到cicsas进程将导致较大的region性能下降，所以建议MaxServer不要太大，仅仅保留最小需要即可。
同时需要检查和增加AIX每个用户的最大进程数，保证dbx的绑定成功。

2.2 使用步骤

1. 准备工作：
a) 上传dumpbt工具,根据内附的readme说明修改$args参数；
b) 建议将MinServer与MaxServer设置为相等，且数值较少；例如MinServer=MaxServer=3。
2. createdumpbt：
执行createdumpbt.sh <region_name>；执行ps –ef | grep dumpbt将观测到针对每个cicsas进程均有相应的dumpbt进程。
3. 运行CICS交易
运行怀疑有内存泄露的交易；执行过程中dumpbt基于CICS的dbx机制，系统处于调试状态。
4. terminatedumpbtscripts：
观察cicstail日志，约半个小时后交易完成后，执行terminatedumpbtscripts.sh完成日志搜集工作。
5. 运行dumpbt_ouput分析工具：./dumpbt_ouput <dumpbt> output.txt
此时的的dumpbt搜集了系统所有的malloc和free操作；可运行dumpbt_ouput生成output文件，里面将包括怀疑有内存泄露的地址。
2.3 dumpbt日志的分析
此处参照《dumpbt日志样本.zip》中的1077426.dumpbt文件。
在dumpbt日志中，执行malloc进行内存分配的例子如下：
malloc_common(??) at 0xd011bc40
_Fancy_malloc(unsigned long)(??) at 0xd153892c
newop.operator new(unsigned long)(??) at 0xd1538440
allocate(unsigned long)(this = 0x30badaa8, size = 24), line 40 in "MemoryManagerImpl.cpp"
..
…
TasTA_Exec(??, ??, ??, ??, ??, ??, ??, ??) at 0xd20e5390
TasTA_Run(??, ??, ??, ??, ??, ??, ??) at 0xd22e39b4
conco_as.main(??, ??) at 0x1000152c

<<< [where] Wed Nov 16 12:15:54 CST 2011

In debuggerCommand_1 CMD = func, PATT =
malloc_common
In debuggerCommand_1 CMD = print $r3, PATT =
0x00000018 《=================内存分配的大小
In debuggerCommand_1 CMD = print $r3, PATT =
0x30f1cab8 《=================内存分配的地址

上述表明程序在地址0x30f1cab8处分配了大小为0x00000018（24字节）的内存：
如果改地址被释放，则应有相应的free操作，如下：
free_common(0x30f1cab8) at 0xd011b960
delop.operator delete(void*)(??) at 0xd1535c1c
deallocate(void*)(this = 0x30badaa8, p = 0x30f1cab8), line 54 in "MemoryManagerImpl.cpp"
xercesc_3_1::ENameMap::~ENameMap()(this = 0x30f1caa0, __dtorFlags = 0, __vtt = (nil)), line 44 in "TransENameMap.hpp"
xercesc_3_1::EEndianNameMapFor<xercesc_3_1::XMLUTF16Transcoder>::~EEndianNameMapFor()(this = 0x30f1caa0, __dtorFlags = 3, __vtt = (nil)), line 67 in "TransENameMap.c"
…
…
TasTA_Exec(??, ??, ??, ??, ??, ??, ??, ??) at 0xd20e5390
TasTA_Run(??, ??, ??, ??, ??, ??, ??) at 0xd22e39b4
conco_as.main(??, ??) at 0x1000152c

<<< [where] Wed Nov 16 12:41:14 CST 2011

In debuggerCommand_1 CMD = func, PATT =
free_common
In debuggerCommand_1 CMD = print $r3, PATT =
0x30f1cab8 《=================内存释放的地址
In debuggerCommand_1 CMD = print $r3, PATT =
0x30006c88

应用需要检查所有被分配的地址有没有被释放，如果对应的malloc没有被free，则需要怀疑此处有内存泄露（需过滤CICS内部调用的地址，参考?2.4 过滤CICS内部调用的地址）。

但往往dumpbt日志较大，此次，实验室提供了dumpbt_ouput分析工具，可筛选出没有被free的地址。
2.4 output日志的分析
此处参照《dumpbt日志样本.zip》中的output文件，共有98个内存地址。
执行./dumpbt_ouput <dumpbt> output.txt后可生成output.txt文件，会列出每一个malloc和free不匹配的记录，举例如下：

ADDR = 0x35241cf8 《=========内存分配的地址
SIZE = 0x006009a4 《=========内存分配的大小

根据提示的ADDR搜索dumpbt确认是否是应用的地址以及是否被正确释放。
（需过滤CICS内部调用的地址，参考?2.4 过滤CICS内部调用的地址）。
2.5 过滤CICS内部调用的地址
此处参照《dumpbt日志样本.zip》中的output文件，共有98个内存地址。
dumpbt_ouput工具产生的output文件包含许多CICS内部调用的地址没有被释放，按照IBM TXSeries实验室的解释，此处的内存占用属于正常情况，该地址将被后续交易中复用或在交易之外被回收，需要排除掉这些地址。
经查阅了以往的CICS内存泄露的PMR，这样的场景出现了多次，且实验室针对以往PMR的质疑在实验室进行过验证，确保类似CICS内部调用不会造成内存泄露。
11月16日 统计分析了output文件中所有98个地址，首先和X行工程师确认了97处不属于应用调用的堆栈。
11月22日 和实验室确认了下面的地址属于CICS的内部调用。
read_msg()
bde_pb_Malloc()
SupER_ConsoleMessage()
rpc_ss_client_get_thread_ctx()
rpc_ss_men_alloc()
pthread_cleanup_push_np()

“ Yes..it looks memory allocated by CICS for functional operation, all
these memory you may not see getting freed after everytime transaction
execution. You dont need to worry about these memory allocation which is
happening from CICS and it won't cause any memory leak.“


作者：张立国