强制内核在SIGSEGV挂钩时转储进程

我写一个RAM值非常有限的系统的应用程序。 由于应用程序崩溃总是可能的，并且它使用dynamic内存分配，所以我创build了所有可能的应用程序停止的callback，并清理所有缓冲区，如下所示：

sigaddset ( &sigact.sa_mask,SIGSEGV ); sigaction ( SIGSEGV,&sigact,( struct sigaction* ) NULL );

它会触发一些通知操作并尝试多次重启。 但是我仍然想知道是什么导致了崩溃，所以我需要crashdump。 GDB不适合这么小的系统，只有内核级别的核心转储是可能的。 但是随着应用程序截获这样一个信号，毕竟它自己退出，内核不会收到信号 – 没有核心创build。

我不能发行

kill(getpid(),kernel_signal);

因为它导致recursion – 这个信号也被拦截。 在这种情况下可能吗？

素数筛中的分割错误

Segfault仅在GDB中显示

最小的C / C ++程序，段错误？

linux：“真正的”分段error handling程序在哪里？

非常奇怪的分割错误在C ++程序之前主要

time（）和gettimeofday（）之间的区别以及为什么会导致seg错误

发生分段错误时停止Linux bash脚本

SWIG包装库中__cxa_allocate_exception期间的segfault

auto_ptr.release（）中的分段错误

Segfault用于嵌套的文件夹调用

也许不是核心转储，你可以打印出一个回溯。 这应该使用较少的内存，是一个可捕捉的信号。 请看这个信号处理程序。

#include <execinfo.h> /* This signal handler ensures clean exits while not running in daemon mode */ void signal_handler(int type) { fprintf(stderr,"nSIGNAL CAUGHT: %d: ",type); switch (type) { case SIGSEGV: { #ifdef GLIBC { void *array[10]; size_t size; // get void*'s for all entries on the stack size = backtrace(array,10); // print out all the frames to stderr fprintf(stderr,"Error: signal %d:n",type); backtrace_symbols_fd(array,size,STDERR_FILENO); // DO CLEANUP HERE } #else // Cause ulibc is terrible fprintf(stderr,"SEGMENTATION FAULT"); // DO CLEANUP HERE break; } #endif case SIGINT: case SIGTERM: case SIGHUP: default: { // DO CLEANUP HERE } } }