Linux下如何捕获SIGSEGV的发生位置？
Linux下编程（尤其是服务端程序）若由于内存越界或其他原因产生“非法操作”，会导致程序悄无声息地死去，初学者往往不知道程序死掉的原因。本人也曾饱受程序死不瞑目之苦。其实“非法操作”在绝大多数时候是因为“段错误”，即 SIGSEGV。而找到SIGSEGV信号抛出的位置，也就找到了程序死掉的原因。下面列出一些捕获SIGSEGV的方法。假设程序名为 myprg，其进程ID(pid)为 2032。方法一：# ./myprg // 运行程序# ps -ef | grep myprg // 找出 myprg 的 pid# gdb myprg 2032 > debug.log // 让 gdb 接管 myprg 的运行# (gdb) continue此方法利用gdb调试器捕获SIGSEGV。上例中，将gdb输出信息存入debug.log，关闭终端，gdb并不退出，继续运行直到 myprg 出错退出。gdb将捕获到出错点。方法二：# ./myprg // 运行程序# Segment fault (core dumped) // 程序死掉了，系统输出 "Segment fault"# gdb myprg core // 用 gdb 分析 core 文件此方法利用core文件，进行事后分析。但前提是保证系统会生成core文件。# ulimit -a查看当前core文件大小的限制，若为0，则需将它改为unlimited。# ulimit -S -c unlimited或修改 /etc/profile，找到 unlimit -S -c 0，将0改为unlimited，重启系统。另外，如果程序安装了 SIGSEGV 异常处理函数，那么 gdb myprg core 时显示的并不是真实的出错位置，要想看到真实的出错点，必须暂时去掉异常处理函数。
Linux下编程（尤其是服务端程序）若由于内存越界或其他原因产生“非法操作”，会导致程序悄无声息地死去，初学者往往不知道程序死掉的原因。本人也曾饱受程序死不瞑目之苦。其实“非法操作”在绝大多数时候是因为“段错误”，即 SIGSEGV。而找到SIGSEGV信号抛出的位置，也就找到了程序死掉的原因。
下面列出一些捕获SIGSEGV的方法。
假设程序名为 myprg，其进程ID(pid)为 2032。方法一：
# ./myprg // 运行程序
# ps -ef | grep myprg // 找出 myprg 的 pid
# gdb myprg 2032 > debug.log // 让 gdb 接管 myprg 的运行
# (gdb) continue
此方法利用gdb调试器捕获SIGSEGV。上例中，将gdb输出信息存入debug.log，关闭终端，gdb并不退出，继续运行直到 myprg 出错退出。gdb将捕获到出错点。方法二：
# ./myprg // 运行程序
# Segment fault (core dumped) // 程序死掉了，系统输出 "Segment fault"
# gdb myprg core // 用 gdb 分析 core 文件
此方法利用core文件，进行事后分析。但前提是保证系统会生成core文件。
# ulimit -a
查看当前core文件大小的限制，若为0，则需将它改为unlimited。
# ulimit -S -c unlimited
或修改 /etc/profile，找到 unlimit -S -c 0，将0改为unlimited，重启系统。
另外，如果程序安装了 SIGSEGV 异常处理函数，那么 gdb myprg core 时显示的并不是真实的出错位置，要想看到真实的出错点，必须暂时去掉异常处理函数。
下面列出一些捕获SIGSEGV的方法。
假设程序名为 myprg，其进程ID(pid)为 2032。方法一：
# ./myprg // 运行程序
# ps -ef | grep myprg // 找出 myprg 的 pid
# gdb myprg 2032 > debug.log // 让 gdb 接管 myprg 的运行
# (gdb) continue
此方法利用gdb调试器捕获SIGSEGV。上例中，将gdb输出信息存入debug.log，关闭终端，gdb并不退出，继续运行直到 myprg 出错退出。gdb将捕获到出错点。方法二：
# ./myprg // 运行程序
# Segment fault (core dumped) // 程序死掉了，系统输出 "Segment fault"
# gdb myprg core // 用 gdb 分析 core 文件
此方法利用core文件，进行事后分析。但前提是保证系统会生成core文件。
# ulimit -a
查看当前core文件大小的限制，若为0，则需将它改为unlimited。
# ulimit -S -c unlimited
或修改 /etc/profile，找到 unlimit -S -c 0，将0改为unlimited，重启系统。
另外，如果程序安装了 SIGSEGV 异常处理函数，那么 gdb myprg core 时显示的并不是真实的出错位置，要想看到真实的出错点，必须暂时去掉异常处理函数。
答：浅析Linux下core文件 当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。最常出 现的，几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们 如何利用core文件找到...
答：通过kill -l 可以查看信号列表，11 是段错误 kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD ...
答：Linux可以使用Ctrl+C结束正在终端运行的程序。也可以使用kill命令来结束指定进程。kill命令是Linux下进程管理的常用命令。通常，终止一个前台进程可以使用Ctrl+C键，但是，对于一个后台进程就须用kill命令来终止，就需要先使用ps/pidof/pstree/top等工具获取进程PID，然后使用kill命令来杀掉该进程。kill命令...
答：示例：在Linux平台上后台运行4个vim进程，使用如下命令即可同时结束掉4个vim进程 ps -efww|grep vim |grep -v grep|cut -c 9-15|xargs kill -9 说明：管道符“|”用来隔开两个命令，管道符左边命令的输出会作为管道符右边命令的输入。“ps -efww”是查看所有进程的命令。这时检索出的进程将...
答：Linux平台上执行malloc()，如果没有足够的RAM，Linux不是让malloc()失败返回，而是向当前进程分发SIGBUS信号。注: 对该点执怀疑态度，有机会可自行测试确认当前系统反应。SIGBUS与SIGSEGV信号的一般区别如下:1) SIGBUS(Bus error)意味着指针所对应的地址是有效地址，但总线不能正常使用该指针。通常是未对齐...
答：HUP是一个信号，这个命令的意思就是给某个程序发送一个HUP信号，不同的程序有可能对这个信号的处理方式不一样，一般来说程序在收到这个信号后都会去重新读取配置信息,如果还不清楚，可以去http://www.chinaunix.net/index.php?uid=20202804 问 ...
答：也就是栈变量，分配在内存的栈区。而linux默认一个程序的线程栈最大是10MB，所以越界了，把S1和S2改小点，比如改成S1[100][100]，就可以正常运行了。4：当然你也可以改linux的线程栈最大值，查下ulimit命令就可以了。或者用malloc将这2个变量动态分配在内存堆区上，堆区一般没限制大小。
答：只在ubuntu上试过， 以例子说明 强制当前shell sigsegv core dump， 当前shell会退出 kill -SIGSEGV core file 已经产生 /var/tmp/cores>ls core 用gdb列出program name gdb GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or ...
答：在Linux上，我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出Core并退出。如果从浅层次的原因上来讲，出Core意味着当前进程存在BUG，需要程序员修复。从深层次的原因上讲，是当前进程触犯了某些OS层级的保护机制，逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如...
答：看看当前目录下是不是有个core或是core.xxx的文件。祭出linux下经典的调试器GDB，首先带着core文件载入程序：gdb exefile core，这里需要注意的这个core文件必须是exefile产生的，否则符号表会对不上。载入之后大概是这个样子的：sagi@sagi-laptop:~$ gdb coredump core Core was generated by ./coredump...
