Linux应用程序崩溃了怎么定位？

摘要：利用backtrace定位嵌入式Linux程序崩溃问题 在嵌入式Linux开发中，多人协作时定位代码崩溃点往往困难。本文介绍使用backtrace工具快速定位崩溃位置的方法。当程序崩溃触发SIGSEGV等信号时，通过signal捕获信号并在handler中调用backtrace获取调用栈信息，配合addr2line工具将地址转换为可读的函数名和行号。关键步骤包括：编译时添加-g调试选项，使用backtrace获取堆栈地址，backtrace_symbols转换地址为字符串，addr2line解析具体代

摘自：http://blog.chinaunix.net/uid-26611383-id-3453351.html 前几天领导安排一个小项目，大意是解决这样一个问题： 在Linux系统下，进程可能由于各种原因崩溃，此时我们要找到出问题的源代码在某一个文件的具体行号，这样调试起来就会方便，高效很多，可能是公司项目要用到，想想挺有意思的，加上自己本身是个Linux狂热者，最终花了两三天解决

如何定位导致Crash的代码位置   2008-07-10 16:13:11|  分类： Visual C++|字号 订阅 1. 在开发环境下定位Crash错误 　　1.1 普通的crash 　　1.2 较难定位的crash 　　1.3 注意vc的输出日志 2. 定位发布在外的版本的Crash错误 3. 小技巧 　　3.1 根据程序地址找到代码位

栈帧信息(gdb) info frameStack level 0, frame at 0x7ffc286552a0:rip = 0x55943b2bb8c4 in foo; saved rip = 0x55943b2bb9e9called by frame at 0x7ffc28655300Arglist at 0x7ffc28655290, args:Locals at 0x7ffc28655...

1. 前言NetHogs是一个开源的命令行工具(类似于Linux的top命令)，用来按进程或程序实时统计网络带宽使用率。来自NetHogs项目网站:NetHogs是一个小型的net top工具，不像大多数工具那样拖慢每个协议或者是每个子网的速度而是按照进程进行带宽分组。NetHogs不需要依赖载入某个特殊的内核模块。如果发生了网络阻塞你可以启动NetHogs立即看到哪个PID造成的这种状况。这样就...

一般而言，项目不会主动加-g来带调试信息，毕竟可执行文件太大了也不够友好。另外，更主要的是，关键时候还不保证会生成core dump文件。这种情况大多是实际要面临的，也是Interviewer喜欢问得。编译时主动带-g，生成的程序带调试信息，而且开启生成dump文件，这时候可以使用core dump来调试程序，定位问题。三、再复杂点：如果core dump文件的堆栈信息被破坏了，又该如何定位问题呢？

栈帧信息(gdb) info frameStack level 0, frame at 0x7ffc286552a0:rip = 0x55943b2bb8c4 in foo; saved rip = 0x55943b2bb9e9called by frame at 0x7ffc28655300Arglist at 0x7ffc28655290, args:Locals at 0x7ffc28655...

栈帧信息(gdb) info frameStack level 0, frame at 0x7ffc286552a0:rip = 0x55943b2bb8c4 in foo; saved rip = 0x55943b2bb9e9called by frame at 0x7ffc28655300Arglist at 0x7ffc28655290, args:Locals at 0x7ffc28655...

2010年8月24日DDD发表评论阅读评 论21: 段错误产生的原因简而言之,产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存, 尤其常见的是访问0地址.一旦一个程序发生了越界访问，系统就采取内存保护措施，并给那个程序发送 SIGSEGV信号，程序接到那个信号后就知道segmentation fault出现了。想对”段错误”有更详细的了解可以去阅读“Linux下的段错误产生的原因及调试方法” 这篇文章，本文的 内容基本是从那文章里提取出来的。2: SIGSEGV

一、导读 Backtrace中，一般都只有一些地址。但是利用addr2line这个工具，就可以找到对应的代码行。前提条件是可执行程序或者动态链接库编译的时候带-g选项。 具体来说，分两种情况： 如果关注的一行backtrace位于一个可执行文件中，那么直接addr2line -e <executable> <address> 如果关注的backtrace位于一个动态链接库中，那么麻烦一些，因为动态链接库的基地址不是固定的。这个时候，首先要把进程的memory ma

linux 程序崩溃，如果能根据已有的插桩日志能排查出来自然好，但是往往日志未全覆盖，这时候排查起来还是比较麻烦的。 一般来说有以下这几种方法获取崩溃现场数据。 core dump core dump是linux原生自带的一个异常分析工具，当程序运行的过程中异常终止或崩溃，操作系统会将程序当时的内存状态记录下来，保存在一个文件中。注意程序编译 需要带 -g。 开启core dump linux 默认是关闭的。 开启 ulimit -c unlimited 此时，运行程序发生sigsegv之类的异常时

Nginx在运行过程中是否稳定，是否有异常退出过？这里总结几项平时会用到的小技巧。1. 在error.log中查看是否有signal项，如果有，看看signal是多少。比如，这是一个异常退出的情况：$grep signal error.log2012/12/24 16:39:56 [alert] 13661#0: worker process 13666 exited on signal 11如果...