Question

今天，我不得不意识到我的C ++模拟程序在运行12天之后崩溃了，在它结束之前只有几行，只剩下一个（截断的）核心转储。

用gdb分析核心转储显示，即

程序以信号SIGBUS，总线错误终止。

并且崩溃发生在我的代码的以下行：

seconds = std::difftime(stopTime, startTime); // seconds is of type double

变量stopTime和startTime的类型为std::time_t，我能够在崩溃时从核心转储中提取它们的值：

startTime: 1426863332
stopTime:  1427977226

difftime-call上方的堆栈跟踪如下所示：

#0  0x.. in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#1  0x.. in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2

我写了一个小程序来重现错误，但没有成功。只使用上述值调用std::difftime(stopTime, startTime)不会导致SIGBUS崩溃。当然，我不希望再发生这种情况。我之前已成功执行过相同的程序（尽管使用不同的参数），执行时间相当。什么可能导致这个问题，如何在将来阻止它？

以下是一些其他系统信息。

GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]  
Linux Kernel: 3.11.10-25-desktop, x86_64
C++ standard library: 6.0.18

修改

这是一些更多的背景。首先，完整的堆栈跟踪（省略号[..]我的）：

#0  0x00007f309a4a5bca in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#1  0x00007f309a4ac195 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#2  0x0000000000465453 in CStopwatch::getTime (this=0x7fff0db48c60, delimiterHourMinuteSecondsBy="") at [..] CStopwatch.cpp:86
#3  0x00000000004652a9 in CStopwatch::stop (this=0x7fff0db48c60) at [..] CStopwatch.cpp:51
#4  0x0000000000479a0c in main (argc=33, argv=0x7fff0db499c8) at [..] coherent_ofdm_tsync_mse.cpp:998

问题出现在程序开头创建的类CStopwatch的对象中。秒表在最顶层的main（）中启动。模拟完成后，将调用函数CStopwatch::stop( )。

秒表类的构造函数：

/*
 * Initialize start and stop time on construction
 */
CStopwatch::CStopwatch()
{
  this->startTime = std::time_t( 0 );
  this->stopTime = std::time_t( 0 );
  this->isRunning = false;
}

函数CStopwatch::stop( )

/*
 * Stop the timer and return the elapsed time as a string
 */
std::string CStopwatch::stop( )
{
  if ( this->isRunning ) {
    this->stopTime = std::time( 0 );
  }
  this->isRunning = false;

  return getTime( );
}

函数CStopwatch::getTime()

/*
 * Return the elapsed time as a string
 */
std::string CStopwatch::getTime( std::string delimiterHourMinuteSecondsBy )
{
  std::ostringstream timeString;

// ...some string init      

  // time in seconds
  double seconds;

  if ( this->isRunning ){
    // return instantaneous time
    seconds = std::difftime(time(0), startTime);
  } else {
    // return stopped time
    seconds = std::difftime(stopTime, startTime); // <-- line where the
                                                  // program crashed
  }

  // ..convert seconds into a string

  return timeString.str( );
}

在程序开始时CStopwatch::start( )被称为

/*
 * Start the timer, if watch is already running, this is effectively a reset
 */
void CStopwatch::start( )
{
  this->startTime = std::time( 0 );
  this->isRunning = true;
}

Answer 1

看起来std::difftime在第一次访问时被延迟加载;如果某些运行时链接程序的内部状态在程序的其他位置已经损坏，则可能导致此问题。

请注意_dl_runtime_resolve必须在std::difftime调用开始之前完成，因此错误不太可能与您的时间值有关。您可以通过在gdb中打开核心文件轻松验证：

(gdb) frame 2 # this is CStopwatch::getTime
(gdb) print this
(gdb) print *this

etc. etc.

如果gdb能够读取并解析地址，并且值看起来很清晰，那肯定不会在运行时导致SIGBUS。或者，您的堆栈可能会被粉碎;如果_dl_fixup正在准备蹦床跳跃，而不仅仅是处理搬迁等;我们不能不确定代码，但可以检查堆栈本身：

(gdb) print %rsp
(gdb) x/16xb $rsp-16 # print the top 16 bytes of the stack

尝试的简单解决方法是设置LD_BIND_NOW环境变量并在启动时强制执行符号解析。这只是隐藏了这个问题，因为某些内存仍然在某处受到损坏，而我们只是隐藏了这个症状。

至于正确解决问题 - 即使短跑没有出现错误，也可能会发生一些记忆损伤但无症状。尝试在valgrind下运行较短的模拟并修复所有警告和错误，除非您确定它们是良性的。

Answer 2

程序在Linux上可能会收到SIGBUS的原因只有几个。有几个列在this question的答案中。

在崩溃期间查看/var/log/messages，您可能会发现磁盘发生故障，或者导致内核不满的其他原因。

另一种（不太可能）的可能性是，有人在程序运行时更新了libstdc++.so.6 ，并且做错了（通过写入现有文件，而不是删除它并创建新文件）在它的位置）。

Answer 3

没有进一步的背景，无法告诉，但是：

this可能是null或损坏
startTime可以是空引用
stopTime可以是空引用

我打算建议您在该行上设置断点并打印出stopTime和startTime，但您已经几乎完成了该操作核心文件。

看起来连接函数时出现了问题。可能是您正在编译来自您链接到的标准库的不同标题集？

它可能与记忆有关：

如果这是深层嵌套的，你可能只是堆栈溢出。
如果这是第一次被调用，可能是它正在尝试为库分配内存，加载它并链接它，并且由于达到内存限制而失败

如果多次调用此代码路径，并且从不在其他地方崩溃，可能是时候在一夜之间运行memtest86。

什么可能导致std :: difftime创建SIGBUS崩溃？

3 个答案: