问题出在加载偶的动态库的进程,在偶服务初始化失败后,其进程并没有完全退出,这样在下一次的服务启动中,由于仍使用原进程,当初始化MIB时,就有下面的问题:
void Mib::construct(const OctetStr& path)
{
... ...
#ifndef STATIC_REQUEST_LIST
requestList = 0;
#endif
#ifdef _SNMPv3
bootCounterFile = DEFAULT_ENGINE_BOOTS_FILE;
#ifdef _PROXY_FORWARDER
if ((requestList) && (requestList->get_v3mp()))
requestList->get_v3mp()->get_local_engine_id(myEngineID);
#endif
#endif
... ...
}
大家注意这句:if ((requestList) && (requestList->get_v3mp()))。实际的coredump就发生在这。
可以看到在agent++.h中,硬性定义了宏
#define _PROXY_FORWARDER
所以这句会执行。同时,由于我的工程在编译时加入了STATIC_REQUEST_LIST宏,所以requestList = 0;不会被执行,这样requestList如果指向非法内存就会coredump。而且,由于这个宏的存在,请看mib.h文件中requestList的定义:
#ifndef STATIC_REQUEST_LIST
RequestList*requestList;
#else
static RequestList*requestList;
#endif
显然requestList是个静态全局变量。
这样在启动过程中,恰好刚初始化MIB完成时,依赖的FM服务被KILL掉,找不到该服务,服务启动失败,做完清理工作后,这时静态指针requestList已经不为空。但进程并没有完全结束,导致该变量仍然有值存在,但实际却已指向无效内存。所以在下次启动后,加载偶服务动态库,就会在agent++中coredump。
较隐蔽的问题,多个原因导致了coredump,解决办法是服务启动失败后如果进程不结束,必须将Mib中的requestList指针置为空。看来对agent++的使用还得注意啊。
分享到:
相关推荐
海思busybox+coredump
如何在让docker中运行的进程生成core dump文件
通过实例来分析linux中如何定位coredump问题。非常实用
Linux Core Dump 权威书籍
在window程序中,添加代码一边在程序崩溃时候产生coredump,能准确定位崩溃地点。
GDB之在线调试与Coredump分析,通过gdb一步步分析coredump文件。
Linux下如何生成core dump
高通core dump解析工具。仅自己上传做个备份。
AIX 下的 core dump 分析入门.mht,html文档,请大家参考以下
coredump栈分析介绍 coredump stack frame-pointer 栈分析 coredump stack frame-pointer 栈分析 coredump stack frame-pointer 栈分析,初学者可参考
Android Coredump简介及使用_v1.0_201504281025.pdf
coredump文件调试
coredump栈分析
core dump 问题定位方法
coredump使用
本文模拟了除零错误发生时,嵌入式arm Linux平台生成的core文件,并在PC端采用arm-gdb解析该core文件,从中可以看出程序崩溃时的函数调用。
請下載本文用到的coredump: Linux Debugging: coredump 分析入門的材料Program received signal SIGSE
要保证存放coredump的目录存在且进程对该目录有写权限。存放coredump的目录即进程的当前目录,一般就是当初发出命令启动该进程时所在的目录。但如果是通过脚本启动,则脚本可能会修改当前目录,这时进程真正 的当前...
囧囧囧囧囧囧囧囧囧coredump_article囧囧囧囧囧囧囧囧囧
Linux应用程序调试之debug_coredump