【原创】Erlang 之 erl_crash.dump 文件分析

      先看一下坚强兄的博文 《 [Erlang 0057] Erlang 排错利器: Erlang Crash Dump Viewer 》 中说了什么: 
1. 基于 crashdump_viewer 的 web 页面进行查看 

crashdump_viewer:start().

补充: 

The Crashdump Viewer is an HTML based tool for browsing Erlang crashdumps. Crashdump Viewer runs under the WebTool application.

2. 基于 recon 的 erl_crashdump_analyzer.sh 分析脚本 进行查看 

-=-=-=-=- 我是88界奥斯卡颁奖礼的分隔线 -=-=-=-=- 

文章中设计到两种工具,下面分别说明 

【crashdump_viewer】 

 
 
 
 
 
 
 
 
 
 
 
 

 erl_crashdump_analyzer.sh  

      该工具是 recon 工具中的其中一个,详细信息可以 参考其 github 上的说明。 

      下面给出 erl_crashdump_analyzer.sh 内容的注释说明 。 

[root@YOYO Erlang]# vi erl_crashdump_analyzer.sh 

#!/usr/bin/env bash
DUMP=$1

echo -e "analyzing $DUMP, generated on: " `head -2 $DUMP | tail -1` "\n"   -- echo -e 表示接受 \ 转义;

### SLOGAN ###
grep Slogan: $DUMP -m 1         -- 仅过滤出一条(即第一条)含有 "Slogan:" 的信息

### MEMORY ###                  -- 内存使用情况统计
echo -e "\nMemory:\n==="
M=`grep -m 1 'processes' $DUMP | sed "s/processes: //"`    -- 获取 "processes: " 后的数值(字节)
let "m=$M/(1024*1024)"
echo "  processes: $m Mb"
M=`grep -m 1 'processes_used' $DUMP | sed "s/processes_used: //"`
let "m=$M/(1024*1024)"
echo "  processes_used: $m Mb"
M=`grep -m 1 'system' $DUMP | sed "s/system: //"`
let "m=$M/(1024*1024)"
echo "  system: $m Mb"
M=`grep -m 1 'atom' $DUMP | sed "s/atom: //"`
let "m=$M/(1024*1024)"
echo "  atom: $m Mb"
M=`grep -m 1 'atom_used' $DUMP | sed "s/atom_used: //"`
let "m=$M/(1024*1024)"
echo "  atom_used: $m Mb"
M=`grep -m 1 'binary' $DUMP | sed "s/binary: //"`
let "m=$M/(1024*1024)"
echo "  binary: $m Mb"
M=`grep -m 1 'code' $DUMP | sed "s/code: //"`
let "m=$M/(1024*1024)"
echo "  code: $m Mb"
M=`grep -m 1 'ets' $DUMP | sed "s/ets: //"`
let "m=$M/(1024*1024)"
echo "  ets: $m Mb"
M=`grep -m 1 'total' $DUMP | sed "s/total: //"`
let "m=$M/(1024*1024)"
echo -e "  ---\n  total: $m Mb"

### PROCESS MESSAGE QUEUES LENGTHS ###
echo -e "\nDifferent message queue lengths (5 largest different):\n==="
grep 'Message queue len' $DUMP | sed 's/Message queue length: //g' | sort -n -r | uniq -c | head -5   -- 排序所有进程的消息队列长度,取消息数最多的 5 个显示出来

### ERROR LOGGER QUEUE LENGTH ###
echo -e "\nError logger queue length:\n==="
grep -C 10 'Name: error_logger' $DUMP -m 1| grep 'Message queue length' | sed 's/Message queue length: //g'  -- 匹配第一条 "Name: error_logger" 行,同时输出其上下各 10 行数据,从这些数据中匹配 'Message queue length: ' 获取其对应值

### PORT/FILE DESCRIPTOR INFO ###
echo -e "\nFile descriptors open:\n==="
echo -e "  UDP: "   `grep 'Port controls linked-in driver:' $DUMP | grep 'udp_inet' | wc -l`  -- udp_inet 对应 UDP 端口使用
echo -e "  TCP: "   `grep 'Port controls linked-in driver:' $DUMP | grep 'tcp_inet' | wc -l`  -- tcp_inet 对应 UDP 端口使用
echo -e "  Files: " `grep 'Port controls linked-in driver:' $DUMP | grep -vi 'udp_inet' | grep -vi 'tcp_inet' | wc -l`  -- 去除 udp_inet 和 tcp_inet 对应的行,剩下的对应 FILE 相关使用(efile 或 tty_sl -c -e 等)
echo -e "  ---\n  Total: " `grep 'Port controls linked-in driver:' $DUMP | wc -l`

### NUMBER OF PROCESSES ###
echo -e "\nNumber of processes:\n==="
grep '=proc:' $DUMP | wc -l     -- 统计进程数量(以 "=proc:" 开头的部分对应进程信息开始)

### PROC HEAPS+STACK ###
echo -e "\nProcesses Heap+Stack memory sizes (words) used in the VM (5 largest different):\n==="
grep 'Stack+heap' $DUMP | sed "s/Stack+heap: //g" | sort -n -r | uniq -c | head -5              -- 获取 "Stack+heap: " 字段后的数值,排序后取前 5 

### PROC OLDHEAP ###
echo -e "\nProcesses OldHeap memory sizes (words) used in the VM (5 largest different):\n==="
grep 'OldHeap' $DUMP | sed "s/OldHeap: //g" | sort -n -r | uniq -c | head -5

### PROC STATES ###
echo -e "\nProcess States when crashing (sum): \n==="
grep 'State: ' $DUMP | sed "s/State: //g" | sort | uniq -c               -- 获取发生 crash 时的全部进程状态(例如 Waiting 或 Running)

分析举例 

[root@YOYO Erlang]# ./erl_crashdump_analyzer.sh erl_crash.dump
analyzing erl_crash.dump, generated on:  Thu Oct 8 09:51:53 2015 

Slogan: init terminating in do_boot ()

Memory:
===
  processes: 13 Mb
  processes_used: 13 Mb
  system: 24 Mb
  atom: 0 Mb
  atom_used: 0 Mb
  binary: 0 Mb
  code: 18 Mb
  ets: 0 Mb
  ---
  total: 38 Mb

Different message queue lengths (5 largest different):
===
     43 0

Error logger queue length:
===
0

File descriptors open:
===
  UDP:  0
  TCP:  2
  Files:  4
  ---
  Total:  6

Number of processes:
===
43

Processes Heap+Stack memory sizes (words) used in the VM (5 largest different):
===
      4 6772
      3 4185
      2 2586
      3 1598
      5 987

Processes OldHeap memory sizes (words) used in the VM (5 largest different):
===
      1 46422
      1 17731
      2 10958
      3 4185
      1 2586

Process States when crashing (sum):
===
      1 Running
     42 Waiting
[root@YOYO Erlang]#

从上面的输出中,可以看到

  • 内存的分配量和使用量
  • 消息队列信息
  • 文件描述符使用信息
  • 堆+栈内存使用量

补充:
      在 lib/observer-2.0/priv/bin 路径下还有一个 cdv 脚本封装了针对 crashdump_viewer 的调用

时间: 2024-09-17 04:18:15

【原创】Erlang 之 erl_crash.dump 文件分析的相关文章

【原创】Erlang 之 erl_crash.dump 生成

-=-=-=-=- 我是<我是歌手 >的分隔线 -=-=-=-=-  (以下为原文引用)        crashdump 对于 erlang 的系统来讲如同 core 对于 c/c++ 程序一样宝贵,对于系统问题的修复提供了最详细的资料.当然 erlang 很贴心了提供了网页版的 crashdump_view 帮助用户解读数据,使用方法如下: crashdump_viewer:start().       因为 crashdump 文本文件里面记录了大量系统相关的信息,这些信息对于分析系统的

dump文件分析-access violation at location 0x000000000000

问题描述 access violation at location 0x000000000000 关机时,程序异常结束,内存不可读写. dump文件分析得到的调用堆栈如下: 根据上面的调用堆栈,好像是回调函数出现问题.请问如何准确定位到代码错误位置? 解决方案 你标框的地方不是已经告诉你了出错的代码文件,行数了,你打开对应的代码分析看看 解决方案二: Unhandled exception at 0x00000000 in CallDll.exe: 0xC0000005: Access viol

dump 分析 windbg-请教dump文件分析问题

问题描述 请教dump文件分析问题 我的程序在客户电脑上偶尔会死机,保存了死机时的DUMP文件,但是看不出问题,哪位大神指导一下? 0:000> !analyze -v * Exception Analysis * * ******************************************************************************* *** ERROR: Symbol file could not be found. Defaulted to expo

AIX的Dump文件学习笔记(原创)

DUMP文件概述  为了增强故障分析能力,IBM的服务器增加了对设备故障当前环境的保存功能,就是保存一份设备故障时的内存.CPU寄存器.IO等设备的数据和状态信息,如果系统并没有停住,只是某个程序死掉,会产生CORE DUMP,在当前目录下产生一个CORE文件.而如果操作系统死掉,则产生System DUMP或者System Crash,通常会引起系统停机.DUMP的记录如下图所示. 作为一般客户通常只需要收集DUMP信息,并反馈给IBM工程师即可.当发生系统DUMP时,机器将会被宕下来.可能的

蓝屏dump文件已分析过 ·求大神指点

问题描述 蓝屏dump文件已分析过 ·求大神指点 Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [D:Desktop61815-9546-01.dmp] Mini Kernel Dump File: Only registers and stack trace are avail

使用Eclipse Memory Analyzer进行堆转储文件分析

简介: Eclipse Memory Analyzer(MAT)是著名的跨平台集成开发环境 Eclipse Galileo 版本的 33 个组成项目中之一,它是一个功能丰富的 JAVA 堆 转储文件分析工具,可以帮助你发现内存漏洞和减少内存消耗.本文主要介绍如 何安装配置 Memory Analyzer,并结合一个实例,介绍如何利用 MAT 来进行堆转 储文件分析,找到内存泄露的根源. 概述 对于大型 JAVA 应用程序来说,再精细的测试也难以堵住所有的漏洞,即便我 们在测试阶段进行了大量卓有成

通过Android trace文件分析死锁ANR实例过程_Android

对于从事Android开发的人来说,遇到ANR(Application Not Responding)是比较常见的问题.一般情况下,如果有ANR发生,系统都会在/data/anr/目录下生成trace文件,通过分析trace文件,可以定位产生ANR的原因.产生ANR的原因有很多,比如CPU使用过高.事件没有得到及时的响应.死锁等,下面将通过一次因为死锁导致的ANR问题,来说明如何通过trace文件分析ANR问题. 对应的部分trace文件内容如下: "PowerManagerService&qu

急求。。。。。看下java的dump文件,会这样

问题描述 急求.....看下java的dump文件,会这样 2015-03-18 22:38:54 Full thread dump Java HotSpot(TM) Client VM (20.1-b02 mixed mode, sharing): "Attach Listener" daemon prio=10 tid=0x089f1c00 nid=0x1df1 waiting on condition [0x00000000] java.lang.Thread.State: RU

windows-Windows下抓取程序崩溃的Dump文件 遇到的问题

问题描述 Windows下抓取程序崩溃的Dump文件 遇到的问题 在Windows环境下,程序崩溃的时候抓取Dump文件,经测试在本机的开发环境下及Win 7环境下 抓取都没有问题,而在Xp和Windows 2003下抓取到的Dump文件都是0KB,这是怎么回事, 有哪位仁兄有这方面经验的还请赐教! 解决方案 Python 批量分析windows程序崩溃捕获的dump文件程序崩溃时抓取dump文件windows程序崩溃生成dump文件 解决方案二: 要看你的API是如何生成dump的,可能是用到