段故障是由于对std::mutex::lock
、si_addr = 0x278
和si_code = SEGV_MAPERR
的读访问造成的。
程序中有太多的内联函数,堆栈只提供了有限的信息,这是不够的。段错误是从某个部署引发的,我们不知道如何重现它。
IMO,0x278
偏移量太小,所以它必须是某个类的偏移量。例如,它应该像下面的情况
struct Dummy
{
char c[0x278];
std::mutex mtx;
};
std::lock_guard lock (reinterpret_cast<Dummy*>(nullptr)->mtx);
字符串
然而,在检查了一些候选类之后,我们发现没有std::mutex
与0x278
有偏移。
所以我想知道是否有什么魔法可以让我们扫描某个命名空间中的所有类,并找到所有在偏移量0x278处定义了std::mutex的类?
编辑
下面是我看到的堆栈。我删除了一些额外的消息,如位置,使其更具可读性。
faultSignalHandler(int, siginfo_t*, void*)
<unknown symbol>
___pthread_mutex_lock
std::__1::mutex::lock()
tDB::LearnerReadWorker::waitUntilDataAvailable(std::__1::unordered_map<unsigned long, DB::RegionLearnerReadSnapshot, std::__1::hash<unsigned long>, std::__1::equal_to<unsigned long>, std::__1::allocator<std::__1::pair<unsigned long const, DB::RegionLearnerReadSnapshot> > > const&, unsigned long, unsigned long)
型
1条答案
按热度按时间1mrurvl11#
然而,在检查了一些候选类之后,我们发现没有std::mutex具有0x 278的偏移量
你是正确的,因为可能有一些
NULL
指针解引用导致访问地址0x278
。然而,这并不意味着在你的某个类中应该有一个具有这样偏移量的
std::mutex
。例如,在Linux / x86_64上使用GLIBC时,反汇编如下所示(在我的系统上):
字符串
如果传递一个
NULL
pthread_mutex_t
,这个函数将在地址0x10
处崩溃。看起来
pthread_mutex_t
* 是使用Clang / libc++的std::mutex
的第一个数据成员,所以可能你应该寻找一个在偏移量0x268
处有std::mutex
的类(如果你的pthread_mutex_lock
匹配我的;如果不匹配,你需要相应地调整偏移量)。P.S.假设你找到一个类
C
,它在所需的偏移量上有std::mutex
。你并没有更接近于找出这个bug,所以这个练习是没有意义的。