gpt4 book ai didi

未知原因的 C++ libpthread 程序段错误

转载 作者:塔克拉玛干 更新时间:2023-11-03 01:12:40 26 4
gpt4 key购买 nike

我有一个 libpthread 链接的应用程序。该应用程序的核心是由四个线程共享的两个 FIFO(两个线程每个一个 FIFO,即;)。 FIFO 类使用 pthread 互斥锁进行同步,它存储指向大类(包含大约 4kb 大小的缓冲区)的指针,这些指针使用重载的 new 和 delete 运算符(此处没有动态分配)在静态内存中分配。

程序本身通常运行良好,但有时会无缘无故地出现段错误。问题是,我无法正确调试段错误,因为我正在使用旧的 linux 内核 (2.4.29) 和 g++ (gcc 版本 egcs-2.91.66 19990314/Linux (egcs-1.1. 2 释放))。

系统上没有 gdb,我无法在其他地方运行该应用程序(它太依赖硬件了)。

我用 -g 和 -rdynamic 标志编译了应用程序,但是当我检查核心文件(只有十六进制地址)时,外部 gdb 什么也没告诉我 - 我仍然可以在捕获 SIGSEGV 后从程序打印回溯 - 它看起来总是像这样:

Backtrace for process with pid: 6279
-========================================-
[0x8065707]
[0x806557a]
/lib/libc.so.6(sigaction+0x268) [0x400bfc68]
[0x8067bb9]
[0x8067b72]
[0x8067b25]
[0x8068429]
[0x8056cd4]
/lib/libpthread.so.0(pthread_detach+0x515) [0x40093b85]
/lib/libc.so.6(__clone+0x3a) [0x4015316a]
-========================================-
End of backtrace

所以好像是指向libpthread...

我通过 valgrind 运行了一些模块,但我没有发现任何内存泄漏(因为我几乎没有使用任何动态分配)。

我认为互斥体可能会造成一些麻烦(因为它们每秒被锁定/解锁大约 200 次)所以我切换了我的简单互斥体类:

class AGMutex {

public:

AGMutex( void ) {
pthread_mutex_init( &mutex1, NULL );
}

~AGMutex( void ) {
pthread_mutex_destroy( &mutex1 );
}

void lock( void ) {
pthread_mutex_lock( &mutex1 );
}

void unlock( void ) {
pthread_mutex_unlock( &mutex1 );
}

private:

pthread_mutex_t mutex1;

};

到一个虚拟互斥类:

class AGMutex {

public:

AGMutex( void ) : mutex1( false ) {
}

~AGMutex( void ) {
}

volatile void lock( void ) {
if ( mutex1 ) {
while ( mutex1 ) {
usleep( 1 );
}
}
mutex1 = true;
}

volatile void unlock( void ) {
mutex1 = false;
}

private:

volatile bool mutex1;

};

但它没有任何改变,回溯看起来是一样的......

在一些 oldchool put-cout-between-every-line-and-see-where-it-segfaults-plus-remember-the-pids-and-stuff 调试 session 之后,它似乎在 usleep 期间出现段错误(?)。

我不知道还有什么问题。它可以工作一个小时左右,然后突然无缘无故地出现段错误。

有没有人遇到过类似的问题?

最佳答案

来 self 的 answer How to generate a stacktrace when my gcc C++ app crashes :

    The first two entries in the stack frame chain when you get into the     signal handler contain a return address inside the signal handler and    one inside sigaction() in libc.  The stack frame of the last function    called before the signal (which is the location of the fault) is lost.

这可以解释为什么您难以通过信号处理程序的回溯来确定段错误的位置。我的answer还包括针对此限制的解决方法。

如果您想查看您的应用程序在内存中的实际布局(即 0x80..... 地址),您应该能够生成一个映射来自 gcc 的文件。这通常通过 -Wl,-Map,output.map 完成,它将 -Map output.map 传递给链接器。

您可能还有硬件特定版本的 objdumpnm使用您的工具链/交叉工具链,这可能有助于破译您的 0x80..... 地址。

关于未知原因的 C++ libpthread 程序段错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2312194/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com