有时当我运行我的代码时，当我通过Ctrl+\终止程序时会生成核心转储文件。文件名的格式为core.*。程序没有突然终止，也没有段错误。我相信它是SIGQUIT而不是SIGABRT或SIGSEGV。如果我尝试Ctrl+C或Ctrl+Z，则它不会生成。谁能说出为什么它只在按下Ctrl+\时生成？如何避免生成此核心转储文件？核心转储文件有什么用吗？ 最佳答案 当一个进程由于程序错误而被操作系统终止时，它会转储核心。发生这种情况的最典型原因是因为程序访问了无效的指针值。鉴于您有零星的转储，很可能您使用的是未初始化的指针。您可以发布导致错误的
我在无法直接访问的远程系统上生成了一个核心文件。我还有来自远程系统的库文件的本地副本，以及崩溃程序的可执行文件。我想在gdb中分析这个核心转储。例如:gdbpath/to/executablepath/to/corefile我的库在当前目录中。在过去，我看到调试器通过提供选项“-p”来实现这一点。或“-p/=”；所以我的问题是:在gdb中分析核心文件时，如何指定首先从相对于当前目录的路径加载库？ 最佳答案 在不指定可执行文件或核心文件的情况下启动gdb，然后键入以下命令:setsolib-absolute-prefix./usrfi
我在无法直接访问的远程系统上生成了一个核心文件。我还有来自远程系统的库文件的本地副本，以及崩溃程序的可执行文件。我想在gdb中分析这个核心转储。例如:gdbpath/to/executablepath/to/corefile我的库在当前目录中。在过去，我看到调试器通过提供选项“-p”来实现这一点。或“-p/=”；所以我的问题是:在gdb中分析核心文件时，如何指定首先从相对于当前目录的路径加载库？ 最佳答案 在不指定可执行文件或核心文件的情况下启动gdb，然后键入以下命令:setsolib-absolute-prefix./usrfi
我的可执行文件包含符号表。但似乎堆栈跟踪被覆盖了。请问如何从该核心中获取更多信息？例如，有没有办法检查堆？查看填充堆的对象实例以获得一些线索。无论如何，任何想法都值得赞赏。 最佳答案 我以C++程序员为生，遇到这个问题的次数比我愿意承认的要多。您的应用程序正在破坏堆栈的巨大部分。很有可能破坏堆栈的函数在返回时也会崩溃。之所以会这样，是因为返回地址被覆盖了，这也是GDB的堆栈跟踪乱七八糟的原因。这是我调试此问题的方式:1)单步执行应用程序，直到它崩溃。(寻找一个在返回时崩溃的函数)。2)一旦你确定了函数，在函数的VERYFIRSTLI
我的可执行文件包含符号表。但似乎堆栈跟踪被覆盖了。请问如何从该核心中获取更多信息？例如，有没有办法检查堆？查看填充堆的对象实例以获得一些线索。无论如何，任何想法都值得赞赏。 最佳答案 我以C++程序员为生，遇到这个问题的次数比我愿意承认的要多。您的应用程序正在破坏堆栈的巨大部分。很有可能破坏堆栈的函数在返回时也会崩溃。之所以会这样，是因为返回地址被覆盖了，这也是GDB的堆栈跟踪乱七八糟的原因。这是我调试此问题的方式:1)单步执行应用程序，直到它崩溃。(寻找一个在返回时崩溃的函数)。2)一旦你确定了函数，在函数的VERYFIRSTLI
我正在设置ulimit-cunlimited.而在c++程序中我们正在做的事情structrlimitcorelimit;if(getrlimit(RLIMIT_CORE,&corelimit)!=0){return-1;}corelimit.rlim_cur=RLIM_INFINITY;corelimit.rlim_max=RLIM_INFINITY;if(setrlimit(RLIMIT_CORE,&corelimit)!=0){return-1;}但是每当程序崩溃时，它生成的核心转储就会被截断。BFD:Warning:/mnt/coredump/core.6685.1325912
我正在设置ulimit-cunlimited.而在c++程序中我们正在做的事情structrlimitcorelimit;if(getrlimit(RLIMIT_CORE,&corelimit)!=0){return-1;}corelimit.rlim_cur=RLIM_INFINITY;corelimit.rlim_max=RLIM_INFINITY;if(setrlimit(RLIMIT_CORE,&corelimit)!=0){return-1;}但是每当程序崩溃时，它生成的核心转储就会被截断。BFD:Warning:/mnt/coredump/core.6685.1325912
已结束。此问题不符合StackOverflowguidelines.它目前不接受答案。要求我们推荐或查找工具、库或最喜欢的场外资源的问题对于StackOverflow来说是无关紧要的，因为它们往往会吸引固执己见的答案和垃圾邮件。相反，describetheproblem以及到目前为止为解决这个问题所做的工作。关闭8年前。Improvethisquestion如果一个进程崩溃并留下一个核心转储，或者我使用gcore创建了一个核心转储，那么我该如何分析它？我希望能够使用jmap、jstack、jstat等并查看所有变量的值。这样我可以找到导致JVM崩溃或卡住的原因。
已结束。此问题不符合StackOverflowguidelines.它目前不接受答案。要求我们推荐或查找工具、库或最喜欢的场外资源的问题对于StackOverflow来说是无关紧要的，因为它们往往会吸引固执己见的答案和垃圾邮件。相反，describetheproblem以及到目前为止为解决这个问题所做的工作。关闭8年前。Improvethisquestion如果一个进程崩溃并留下一个核心转储，或者我使用gcore创建了一个核心转储，那么我该如何分析它？我希望能够使用jmap、jstack、jstat等并查看所有变量的值。这样我可以找到导致JVM崩溃或卡住的原因。
我想通过调用在脚本中编写的预定义命令来获取导致崩溃的线程的堆栈跟踪，以便我运行脚本并获得包含所有线程的反向跟踪的日志文件。然后我可以解析此日志文件以查看是否存在已知问题。 最佳答案 我建议您看一下cdb.它是windbg的一个功能非常全的命令行版本，应该已经与windbg一起安装了。您可以告诉它打开转储、打印堆栈跟踪并使用命令行退出:cdb-zyourdump.dmp-c"~*kv;q"或者您甚至可以幻想并使用以下方法进行一些自动化分析:cdb-zyourdump.dmp-c"!analyze-v;q"这可能更有意义，因为它会在第二
