谷歌核心转储程序返回不允许的操作

google-coredumper returns Operation not permitted

本文关键字：不允许 操作 返回 程序 核心 转储 谷歌      更新时间：2023-10-16

背景：从 code.google.com 下载google-coredumper-1.2.1.tar.gz。 构建代码并进行安装。为我的应用程序添加了库和函数调用并执行。没有核心文件，日志状态不允许操作。因此，我创建了一个简单的示例并逐步浏览了它，发现该库认为可执行文件已被跟踪。有什么想法吗？

#include <string>
#include <stdio.h>
#include <stdlib.h>
#include "crashtest.h"
#include <google/coredumper.h>
#include <errno.h>
#include <string.h>
#include <signal.h>
FILE    * backtrace_file = NULL;
#define SIZE 100
void CREATE_COREDUMP()
{
  printf("NOTICE, Creating a core dump for debuggingn");
  char    extension[64];
  time_t  t       = time((time_t*)NULL);
  tm    * theTime = localtime(&t);
  snprintf( extension,
          sizeof(extension) - 1,
          "core.crashtest_02d_%02d_%02d_%02d", (theTime->tm_mday),
                                               (theTime->tm_hour),
                                               (theTime->tm_min) ,
                                               (theTime->tm_sec) );
  if (WriteCoreDump(extension) != 0) {
    std::string errmsg(extension);
    errmsg.append(" : ");
    errmsg.append(strerror(errno));
    printf("WARNING, Failed to create coredump: %sn", errmsg.c_str() );
  }
}
static void mysighandler(int sig)
{
  printf("ERROR, Somebody Segmentation Faulted. About to Exitn");
  CREATE_COREDUMP();
  exit(0);
}
crashtest::crashtest() {
  char * errcond = NULL;
  memcpy(errcond, "Crash This", 10);
}
crashtest::~crashtest() {}
int main(int argc, char** argv) {
  struct sigaction sa;
  sa.sa_flags = SA_SIGINFO;
  sigemptyset(&sa.sa_mask);
  sa.sa_handler = &mysighandler;
  sigaction(SIGSEGV, &sa, NULL);
  crashtest ct;
  return 0;
}

练习的要点是主代码偶尔会生成分段错误，这没有意义，因为所有值都已初始化。因此，我试图找出为什么存在分段错误，并希望获得一个内核来跟踪有问题的代码行。我不能只是杀人，因为需要代码才能恢复和继续。这就是为什么谷歌核心转储器被认为是被使用的。

根据 http://www.gossamer-threads.com/lists/linux/kernel/622686 的说法，当前状态下的核心转储程序似乎不再可用：

我相信，如果我正确解释 kernel.org 上的数据，这 更改由 Linus 进行，并在 2.6.15 中发布。

perftools和coredumper都需要找到活动中的所有线程 应用程序才能工作。由于 libpthread 已经发生了变化和 文档记录不佳的 API 来获取此信息，因为我们的目的是 为了支持所有内核版本和所有libc版本，我们采用了 跟踪任何怀疑是我们线程之一的进程 以便确定它是否真的是。这具有以下额外好处： 查找所有线程（包括不由 libpthread 管理的线程）和 暂时挂起它们，以便我们有一个稳定的内存映像 我们可以检查。将这两种工具视为类似 轻量级进程内调试器。

显然，必须特别注意不要追踪我们自己的线程， 并避免任何可能死锁的库调用。

在补丁之前，将 ptrace 附加到我自己的线程是有效的 操作。有了这个新补丁，我不能再这样做了。

相关文章：