c++ - google-coredumper 返回 Operation not permitted

Question

背景:从 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 debugging\n");
  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: %s\n", errmsg.c_str() );
  }
}

static void mysighandler(int sig)
{
  printf("ERROR, Somebody Segmentation Faulted. About to Exit\n");

  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;
}

练习的要点是主代码偶尔会产生段错误，这没有意义，因为所有值都已初始化。因此，我试图发现为什么存在段错误，并希望获得一个核心来追踪有问题的代码行。我不能只是杀死，因为恢复和继续需要代码。这就是为什么人们认为使用 google-coredumper 的原因。

Answer 1

根据 http://www.gossamer-threads.com/lists/linux/kernel/622686 ，目前的 coredumper 似乎不再可用:

I believe, if I interpret the data on kernel.org correctly, this change was made by Linus and shipped with 2.6.15.

Both perftools and coredumper need to locate all threads in the active application in order to work. As libpthread has had changing and poorly documented APIs to get this information, and as our intent is to support all kernel versions and all libc versions, we resorted to ptracing any process that is suspected to be one of our threads in order to determine if it actually is. This has the added benefit of finding all threads (including ones not managed by libpthread) and of temporarily suspending them, so that we have a stable memory image that we can inspect. Think of both tools as something like a lightweight in-process debugger.

Obviously, special care has to be taken to not ptrace our own thread, and to avoid any library calls that could deadlock.

Before the patch, attaching ptrace to my own threads was a valid operation. With this new patch, I can no longer do that.