静态库覆盖动态库同名类以及方法

已于 2024-07-04 17:41:51 修改
阅读量445 收藏
点赞数
文章标签： oracle 数据库
于 2022-07-02 17:34:01 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_42896627/article/details/125573819
版权

某天某个客户反馈他们测试环境，客户端上报的审计信息无法插入Oracle数据库，最近他们升级了Oracle，想问下是不是升级导致的，不过刚好这个时间，有新需求。给客户提供了新包，也可能是自己改代码搞出来的bug，而不是升级导致的

让现场同事采集了下堆栈信息，我们抽出有用的信息(此现场无法远程)

Thread 16 (Thread 0x7f7cf07e0700 (LWP 5519)):
#0  0x00007f7db0d4b54d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f7db0d46e9b in _L_lock_883 () from /lib64/libpthread.so.0
#2  0x00007f7db0d46d68 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00000000012b6c31 in HIEUtil::RecMutex::lock (this=0x7f7db4c43548 <HOTLDBMgrOracle::sta_ins+936>)
    at ../HIERecMutex.cpp:249
#4  0x00007f7db49bd89a in HOTLDBMgrOracle::get_connect (this=0x7f7db4c431a0 <HOTLDBMgrOracle::sta_ins>, ui_id=@0x7f7cf07df9bc: 32637, str_exec_sql=...)
    at ../../../../../../BlowSnow_PUFA/source/DBOracle/HOTLDBMgrOracle.h:1991
#5  0x00007f7db49bbff7 in HOTLDBMgrOracle::do_exec_sql (this=0x7f7db4c431a0 <HOTLDBMgrOracle::sta_ins>, str_sql=..., i_buffer_size=4096)
    at ../../../../../../BlowSnow_PUFA/source/DBOracle/HOTLDBMgrOracle.h:1631
#6  0x00007f7db49c460c in DBBatInsertAuditInfoCommon::insert_general_config_warningInfo (lst_audit_infos=std::list<std::pair<AuditCommonInfo, LVPReportUserActionMonVT>, std::allocator<std::pair<AuditCommonInfo, LVPReportUserActionMonVT> > >::_Node: 
std::list) at DBBatInsertAuditInfoCenterOracle.cpp:947
#7  0x0000000000cba179 in DBBatInsertAuditInfoCommon::insert_audit_info(std::list<std::pair<AuditCommonInfo, LVPReportUserActionMonVT>, std::allocator<std::pair<AuditCommonInfo, LVPReportUserActionMonVT> > > const&) ()
#8  0x0000000000bdbf4c in DBBatInsertAuditInfoThread<std::pair<AuditCommonInfo, LVPReportUserActionMonVT> >::run() ()
#9  0x00000000012bb0b7 in HThreadReal::run (this=0x7f7d0c002440)
    at ../HThreadPool.cpp:213
#10 0x0000000001290827 in startHook (arg=0x7f7d0c002440)
    at ../HIEThread.cpp:606
#11 0x00007f7db0d44ea5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f7db0a6db0d in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7f7cfc7f8700 (LWP 6881)):
#0  0x00007f7db0d4b54d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f7db0d46e9b in _L_lock_883 () from /lib64/libpthread.so.0
#2  0x00007f7db0d46d68 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00000000012b6c31 in HIEUtil::RecMutex::lock (this=0x7f7db4c43548 <HOTLDBMgrOracle::sta_ins+936>)
    at ../HIERecMutex.cpp:249
#4  0x00007f7db49bd89a in HOTLDBMgrOracle::get_connect (this=0x7f7db4c431a0 <HOTLDBMgrOracle::sta_ins>, ui_id=@0x7f7cfc7f76dc: 32637, str_exec_sql=...)
    at ../../../../../../BlowSnow_PUFA/source/DBOracle/HOTLDBMgrOracle.h:1991
#5  0x00007f7db49bbff7 in HOTLDBMgrOracle::do_exec_sql (this=0x7f7db4c431a0 <HOTLDBMgrOracle::sta_ins>, str_sql=..., i_buffer_size=4096)
    at ../../../../../../BlowSnow_PUFA/source/DBOracle/HOTLDBMgrOracle.h:1631
#6  0x00007f7db49c2c70 in DBBatInsertAuditInfoCommon::insert_cloud_monitor (lst_audit_infos= const std::list<std::pair<AuditCommonInfo, LVPReportCoudMonitoringVT>, std::allocator<std::pair<AuditCommonInfo, LVPReportCoudMonitoringVT> > >::_Node: std::list) at DBBatInsertAuditInfoCenterOracle.cpp:701
#7  0x0000000000cba0e9 in DBBatInsertAuditInfoCommon::insert_audit_info(std::list<std::pair<AuditCommonInfo, LVPReportCoudMonitoringVT>, std::allocator<std::pair<AuditCommonInfo, LVPReportCoudMonitoringVT> > > const&) ()
#8  0x0000000000bdd85c in DBBatInsertAuditInfoThread<std::pair<AuditCommonInfo, LVPReportCoudMonitoringVT> >::run() ()
#9  0x00000000012bb0b7 in HThreadReal::run (this=0x7f7d0c03a9c0)
    at ../HThreadPool.cpp:213
#10 0x00000000012907d0 in startHook (arg=0x7f7d0c03a9c0)
    at ../HIEThread.cpp:585
#11 0x00007f7db0d44ea5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f7db0a6db0d in clone () from /lib64/libc.so.6

看到这个很容易想到其它地方获取锁卡住导致这里获取锁时获取步到，因此卡住了。但是除此之外没有其它请求锁的线程栈了，已经让现场同事采集了好几次，都是这样的堆栈。既然不是别的地方获取锁导致执行sql语句的接口卡住了，那么怀疑可能是mutex的内存被写坏了导致的。

按照这个思路，并且发现后台有个记录sql执行以及异常时相关信息的日志UniServer_DBEXInfo_0.log，发现每次卡住都能看到类似的sql。那就根据这个日志和堆栈，在HOTLDBMgrOracle.h 文件中找到HOTLDBMgrOracle::do_exec_sql函数，一步步查吧

[1][2022-07-01][11:01:07][T2784966400][HOTLDBMgrOracle.h   ][1489][E]Msg:ORA-00903: invalid table name
, STM:update  set  = -1 where uidrecordid  = '064420220628tNiyhZuTdpPCGl80', State:, Var:, id 0

找到HOTLDBMgrOracle.h 文件中的HOTLDBMgrOracle::do_exec_sql函数

HOTLStreamOracle* HOTLDBMgrOracle::do_exec_sql(const HString& str_sql,int i_buffer_size)
{
       ...
       ...
       实现省略了

        try
        {
               ...
        }
        catch( oracle::otl_exception &ex)
		{
                HString str_tips ;
                str_tips << L"Do exec " << str_sql << L" exception:"<<otl_exception2str(ex);
                m_file_ex_log.log(m_file_ex_log.get(LEL_TIPS,__WFILE__,__LINE__)<<str_tips);

                if (p_stream->pos)
                {
                        delete p_stream->pos;
                        p_stream->pos = 0;
                }
                delete p_stream;
                p_stream = 0;
                del_ref(ui_id);
                do_ex(ex, ui_id);
        }
        return p_stream;
}

//跟着catch里的处理逻辑到do_ex函数
void HOTLDBMgrOracle::do_ex(oracle::otl_exception& ex, unsigned int ui_id)
{	
	//otl_exception2str(ex)这个接口打印了上面所说的日志，如下，所以接着堆栈往下跟踪
	/*
	HString otl_exception2str(oracle::otl_exception& p)
	{
     	HString str;
        HString str_error((char*)(p.msg)) ;
        std::string ice_error((char*)p.msg);
        printf(ice_error.c_str());
        str_error.make_by_ice_str(ice_error);
        str << L"Msg:" << str_error << L", STM:" << p.stm_text << L", State:" << p.sqlstate
                << L", Var:" << p.var_info;
        return str;
	}
	*/
	
	HString str_show = otl_exception2str(ex) << L", id " << ui_id;
	m_file_ex_log.log(m_file_ex_log.get(LEL_ERROR , __WFILE__,__LINE__)<<str_show);

	if(...)
	{
		HLog(HGET_INFO << L"set to recon");
		HIEUtil::RecMutex::Lock lock(mutex);
		for (int i = 0; i < mvt_connector.size(); i++)
		{
			if (mvt_connector[i].i_status == HOTLCS_CON_ED)
			{
				mvt_connector[i].i_status = HOTLCS_CON_NO;
				if (!mb_thread_run)
				{
					mb_thread_run = true;
					HThreadDBMMaintain* pt = new HThreadDBMMaintain;
					pt->mdm = this;
					pt->start().detach();
				}
			}
		}
	}
}
//接着跟HThreadDBMMaintain类
class HThreadDBMMaintain: public HIEUtil::Thread
{
public:
	HOTLDBMgrOracle* mdm;
	virtual void run()
	{
		mdm->run();
	}
};

//接着跟run函数
void HOTLDBMgrOracle::run()
{
	HLog(HGET_INFO << L"run start");
	while(1)
	{
		bool b_need = need_recon();
		if (b_need)
		{
			HLog(HGET_INFO << L"need_recon");
			oracle::otl_connect* p_connect = get_new_connect();
			HLog(HGET_INFO << L"get_new_connect ret " << (__int64)p_connect);
			if (p_connect == 0)
			{
				HEnvironment::Sleep(1000 * 20);
				continue;
			}
			add_new(p_connect);
		}
		else
		{
			HEnvironment::Sleep(1000 * 2);
		}
	}
}

但是我们发现UniServer_0.log日志种发现显示的文件名并不是HOTLDBMgrOracle.h而是HOTLDBMgr.cpp

[1351][2022-07-01][11:01:07][T2835322624][HOTLDBMgr.cpp       ][0879][I]run start
[1352][2022-07-01][11:01:07][T2835322624][HOTLDBMgr.cpp       ][0887][I]need_recon
[1353][2022-07-01][11:01:07][T2835322624][HOTLDBMgr.cpp       ][0747][I]mstr_user scmsbusinessdb mstr_dsn OracleDB
[1354][2022-07-01][11:01:07][T2835322624][HOTLDBMgr.cpp       ][1648][I]rlogon take time 58 ms
[1355][2022-07-01][11:01:07][T2835322624][HOTLDBMgr.cpp       ][0891][I]get_new_connect ret 140437713089200

但是日志里的“run start" “need_recon” "get_new_connect ret"信息不会有错，但为什么会日志会打印显示HOTLDBMgr.cpp文件名，(按照预期应该是HOTLDBMgrOracle.h)，此时我们翻阅HOTLDBMgr.cpp这个文件的代码，发现两个文件中有同名的类HThreadDBMMaintain，细想下编译不会报错么。

class HThreadDBMMaintain  : public HIEUtil::Thread
{
public:
	HOTLDBMgr* mdm;
	virtual void run()
	{
		mdm->run();
	}
};

经过资料的查询以及自己写demo测试，发现动态库同名的类以及方法调用时确实会被静态库的所覆盖
（当然前提是你要在代码中的某处调用了这个同名类，否则仅仅只是定义在那里，即便同名了也不会覆盖，还是各自调用各自的）
HOTLDBMgr.cpp .h被制作成了静态库
HOTLDBMgrOracle.h被制作成了动态库
因为项目的特殊性，然后一起被链接到我们的程序里了

======================================================
再次回到这里HOTLDBMgrOracle::do_ex这里。因为动态库同名类以及方法调用被静态库覆盖了，所以HThreadDBMMaintain* pt = new HThreadDBMMaintain; new出来的是HOTLDBMgr.cpp中的HThreadDBMMaintain，而这个文件中的HThreadDBMMaintain类的成员mdm类型是HOTLDBMgr*，this指针的类型是HOTLDBMgrOracle*。这里执行了pt->mdm = this;

虽然不能远程使用gcore，无法知道具体的细节，但是可以猜测的是，这里将不同类的实例赋值并且进行相关函数调用和成员赋值操作，HOTLDBMgr和HOTLDBMgrOracle的类内存分布是不一样的，所以导致了HOTLDBMgrOracle里的mutex变量内存被踩坏，故堆栈lock的时候卡住从而数据无法入库。

后续将lock改为trylock发现返回值为16，该锁已经被占用，说明我们这个猜测是有可能性的，碍于没法远程不知道具体细节，就暂时搁置

void HOTLDBMgrOracle::do_ex(oracle::otl_exception& ex, unsigned int ui_id)
{
	HString str_show = otl_exception2str(ex) << L", id " << ui_id;
	m_file_ex_log.log(m_file_ex_log.get(LEL_ERROR , __WFILE__,__LINE__)<<str_show);

	if(...)
	{
		HLog(HGET_INFO << L"set to recon");
		HIEUtil::RecMutex::Lock lock(mutex);
		for (int i = 0; i < mvt_connector.size(); i++)
		{
			if (mvt_connector[i].i_status == HOTLCS_CON_ED)
			{
				mvt_connector[i].i_status = HOTLCS_CON_NO;
				if (!mb_thread_run)
				{
					mb_thread_run = true;
					HThreadDBMMaintain* pt = new HThreadDBMMaintain;
					pt->mdm = this;
					pt->start().detach();
				}
			}
		}
	}
}

//而pt->start()也就是调用了HOTLDBMgr::run(),而其中再次调用的相关接口也确实访问甚至赋值了相关变量
void HOTLDBMgr::run()
{
        HLog(HGET_INFO << L"run start");
        while(1)
        {
                bool b_need = need_recon();
                if (b_need)
                {
                        HLog(HGET_INFO << L"need_recon");
                        otl_connect* p_connect = get_new_connect();
                        HLog(HGET_INFO << L"get_new_connect ret " << (__int64)p_connect);
                        if (p_connect == 0)
                        {
                                HEnvironment::Sleep(1000 * 20);
                                continue;
                        }
                        add_new(p_connect);
                }
                else
                {
                        HEnvironment::Sleep(1000 * 2);
                }
        }
}

故将HOTLDBMgrOracle.h中的HThreadDBMMaintain类名以及用过改类名的地方全部修改为HThreadDBOracleMMaintain，重新编译后给到现场验证。入不了库的问题不在出现

题外话：之前一直没出现是因为没有sql语句执行异常或者有sql执行异常但不满足条件，而新交付的测试包拼接sql的时候正好出现update set = -1 where uidrecordid = '064420220628tNiyhZuTdpPCGl80’这种有问题的sql，导致进入catch分支里面并且满足条件，走到HThreadDBMMaintain* pt = new HThreadDBMMaintain;这里。才引发了这个bug。时也，命也

　　　　free
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Linux动态库与静态库同名函数链接顺序问题
mrhjlong
03-04 1448
linux gcc编译链接动态库与静态库同名函数顺序问题
静态库与动态库
qq_43761725的博客
03-19 123
静态库和动态库
动态库 版本_GCC当同时链接同名的静态库和动态库的时候的行为分析
weixin_36232899的博客
01-13 980
如果我们这么写，同时对一个.o既编译了静态库又编译了动态库并且同时link到app,首先我们可以在app中看到这个foo的符号为T，表示已经在.text字段，其次当我们通过ldd查看的时候，还能看到他对libfoo.so的依赖这个时候当我们重新编译libfoo.so来查看到底最终他用的是哪个版本的foo的时候，我们发现他虽然dynamic link了libfoo.so,但是因为他自己的text段已...
Ubuntu——gcc：gcc介绍以及静态库与动态库的生成与使用
最新发布
Morzart的博客
09-21 929
调用动态库的时候有几个问题会经常碰到，有时，明明已经将库的头文件所在目录 通过 “-I”include 进来了，库所在文件通过 “-L”参数引导，并指定了“-l”的库名，但通过 ldd 命令察看时，就是死活找不到你指定链接的 so 文件，这时你要作的就是通过修改LD_LIBRARY_PATH 或者/etc/ld.so.conf 文件来指定动态库的目录。这样，加入的目录下的所有库文件都可见。当静态库和动态库同名时，gcc 命令将优先使用动态库，默认去连/usr/lib 和/lib 等目录中的动态库。
ＣＭａｋｅ生成的动态库和静态库名称一致
tianyingang的博客
07-02 1123
cmake_minimum_required(VERSION 3.5 FATAL_ERROR) project(recipe-04 LANGUAGES CXX) add_library(message-objs OBJECT Message.cpp Message.hpp ) set_target_properties(message-objs...
Python库 | jinja2-dev-server-0.0.2b17.tar.gz
03-06
2. **块（Blocks）**：块是模板中的可重写区域，子模板可以通过定义同名块来覆盖父模板的内容。 3. **环境（Environment）**：环境是Jinja2的一个核心概念，它包含了模板加载器、配置信息以及全局变量等，用于管理...
linux 下同名符号冲突问题解决方案
09-15
- 模块 `bb` 编译连接得到 `bb.a` 静态库，也包含了一个名为 `do()` 的函数，但其实现与 `cc` 模块中的 `do()` 不同； - 模块 `aa` 通过 `-lbb` 链接选项链接了 `bb.a`，并在运行时调用了 `bb` 模块中的 `bb_fun()` ...
CheckCategoryConflict:自动检测项目代码、静态库等开源和非开源的项目间存在的 Category 冲突，用于避免不可预期的同名扩展
07-06
然而过度的不正确的使用，容易导致项目中存在 Category 同名函数冲突，这种同名冲突无法自动检测，导致同名函数互相覆盖，代码最终执行到哪个具体函数不可确定，直接后果是出现不可预期的、很难排查的问题。...
类的多态练习_C++_类的多态练习_
09-29
首先，我们要明白多态性的两种主要形式：静态多态（Static Polymorphism）和动态多态（Dynamic Polymorphism）。静态多态主要通过函数重载（Function Overloading）和运算符重载（Operator Overloading）实现，...
浙江工商大学题库UML.doc
10-12
- **重载(Overload)**：在同一类中定义多个同名方法，但它们有不同的参数列表。例如，在类`A`中定义了两个名为`setValue`但参数类型不同的方法。 ### 6. 多态性的实例 - 在面向对象编程中，多态是指相同的方法名...
技巧：多共享动态库中同名对象重复析构问题的解决方法
yuyin86的专栏
08-24 1304
技巧：多共享动态库中同名对象重复析构问题的解决方法 共享库与静态成员 吴 光远, 软件工程师, IBM 孟 先涛, 软件工程师, IBM 简介： Linux 平台下的共享动态库，一般都是通过选项“-fPIC”编译出来。有些应用程序需要链接多个共享库，此时如果在这些共享库中存在相同作用域范围的同名静态成员变量，那么当程序访问完静态成员变量结束析构时，由于内存的 d
多个同名的动态库使用时如何避免冲突
我要出家当道士
09-06 1114
多个同名的动态库使用时如何避免冲突
有关动态库和静态库的生成和加载
jfkidear的专栏
08-22 746
有关环境变量： LIBRARY_PATH环境变量：指定程序静态链接库文件搜索路径 LD_LIBRARY_PATH环境变量：指定程序动态链接库文件搜索路径 静态库链接时搜索路径顺序： 1. ld会去找GCC命令中的参数-L 2. 再找gcc的环境变量LIBRARY_PATH 3. 再找内定目录 /lib /usr/lib /usr/local/lib 这是
检查静态库中的同名函数
weixin_34150224的博客
09-29 594
静态库中可以有同名函数 这种做法肯定不是bad practice。但是误操作可能导致这个问题的出现。 可以通过C++的namespace来解决这个问题。不过我不写C++，那么忽略它。 例子 test.h: #include &lt;stdio.h&gt; void play(); test.c void play() { printf("play\n"); } test_old.c voi...
c++使用多个库的头文件内容里有名字相同问题
zhouk的专栏
11-11 7052
首先说下结构体，如果两个头文件定义的结构体内容不一样，但名字一样，当一个文件同时包含着两个头文件的时候，就会报如下错误： 此时，在不修改头文件的情况下(最好不要改动，不然第三方库可能调用出错)，使用命名空间可以解决这个问题，把两个头文件放到两个不同的命名空间里，例如： 再说下预定义，打个比方当头文件1里使用了#define WORD unsigned short 头文件2里使用了 typedef unsigned short WORD; 当一个文件先#include <头...
深析静态链接库和动态链接库相同函数覆盖及库调用顺序问题
好习惯成就伟大
02-19 1712
注意：编译器为gcc，若使用g++，请在库里面加上extern “C” 两个静态库 首先测试静态链接库，大概的代码如下： liba.c #include<stdio.h> #include<stdlib.h> #include"libA.h" void libA() { common(); } void common() { printf("libA common!\n"); } li...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值