首先,android平台应用程序可能产生以下四种crash:App层:Force close crashANR crashNative层:Tombstone crashKernel层:Kernel panic比较难定位,可以查看/proc/last_kmsg来辅助定位. 最近需要通过monkey工具测试Tombstone类型的crash,抓取log并分析.通过monkey测试,如果要抓取native类型的crash,需要加上--monitor-native-crash参数: seed=$(dat

Build fingerprint: 'XXXXXXXXX'pid: 1658, tid: 13086  >>> system_server <<<signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e r0 00000000  r1 00000001  r2 ad12d1e8  r3 7373654d r4 64696f72  r5 00000406  r6 00974130  r7 40d1400

有一句话叫做常在河边走,哪有不湿鞋.我们这些研究和开发Android的project师正应了这句话,相必大家在调试的时候常常会遇到这么个东西吧 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'XXXXXXXXX' pid: 1658, tid: 13086  >>> system_server <<< signal 11 (SIGSEGV), code

转自:http://weibo.com/p/230418702c2db50102vc2h Android 虽然已经有好几年了,但是NDK的开放速度却非常缓慢,所以目前网络上针对对Android NativeCrash的分析说明还比较少,尤其是非常详细的分析方式更难以查询.因此大部分程序员在遇到难以进行addr2line的crashlog时,会一筹莫展.事实上这份log中的其他部分同样提供了非常丰富的信息可供解读,所以在这里总结一下对在这方面的一些经验,在这里以Androidsamples中的he

Android平台程序崩溃大家都应该遇到过,force close和ANR应该是大家遇到较多的. 这里把Android平台程序崩溃的各种类型做一个简述和原因列举. 1.ANR(可见ANR): 发生场景:应用发生ANR. 崩溃症状:系统弹出窗口询问用户选择"Force Close"或者"Wait".        "Force Close"将杀掉发生ANR的应用进程."Wait"将会等待系统择机恢复此应用进程. 发生原因: (1

本文介绍了如何在 Android 手机发生 Crash 时进行 Log 分析的方法, 它可以帮助测试人员快速定位 Android 手机 Crash 发生的原因,同时给研发人员提供有效修改 Bug 的 Log 信息. 用自动化测试工具对 Android 手机进行压力测试和稳定性测试,往往通过模拟实际使用场景中所发生的业务量来测试手机性能是否满足要求,测试过程中系统状态信息被实时记录到 Log 文件中,通过对 Log 信息的分析,可以检查到错误发生的根源和运行痕迹,因此,有效利用 Log 信息并对其

在实际的Android开发过程中,我们遇到了一些奇奇怪怪的Crash,通过sigaction再配合libcorkscrew以及一些第三方的Crash Reporter都捕获不到发生Crash的具体信息,十分头疼.然后我们通过Bugly上报的Java的CallStack观察发现这些Crash发现了一些共同的信息: 看来是和OpenGL有关系,于是我们进一步对程序输出的log进行观察,又发现: 从这个log里面我们获得了几个信息: 几乎所有出现这种Crash的设备,都是Adreno的GPU 几乎所有

1.简介 IOS是由苹果公司为iPhone.iPod touch和iPad等设备开发的操作系统. 2.知识点 iPhone OS(现在叫iOS)是iPhone, iPod touch 和 iPad 设备的操作系统. iOS系统架构:基于UNIX.分为4个层次:核心操作系统层(最底层)Core OS核心服务层 Core Services媒体层 Media可触摸层 Cocoa Touch 1.Core OS: 它是用FreeBSD和Mach所改写的Darwin, 是开源.符合POSIX标准的一个Un

最近在做服务器的稳定性的相关测试,服务器的网络底层使用的是boost asio,然后自己做的二次封装以更好的满足需求. 服务器昨天晚上发现crash了一次,之前测试了将近半个多月,有一次是莫名的退出了,不过由于是新的测试服,忘记将ulimit -c进行修改了,所以没有coredump,这次又发生了. coredump如下: #0 0x0000000000000091 in ?? () #1 0x0000000000459729 in ClientHandler::HandleConnect(cp

小优有话说: App Crash就像地雷. 你怕它,想当它不存在.无异于让你的用户去探雷,一旦引爆,用户就没了. 你鼓起勇气去扫雷,它却神龙见首不见尾. 你告诫自己一定开发过程中减少crash,少埋点地雷,但总是不得其法. 降低Crash率,需要的是技巧.工具.耐心与时间. 本文由腾讯天天P图测试团队现身说法,为你讲述他们将Crash率直降90%背后的故事,希望能为你“排雷”提供一些思路. PS:以后每周四记得关注这里哦!小优将为你精选“干货”,让腾讯的开发&测试大牛们陪你一起为提升产品质量!

http://code.google.com/p/innosoc/wiki/KernelBootCrashDebug 注: 如在i386_start_kernel中加入:early_printk("in i386_start_kernel\n"); console可以立即看到,不用等到console_init后 kernel启动控制台还不可用时发生crash的调试方法 在调试linux kernel时，如果crash发生在控制台还不可用时，那将没有任何信息能够被打印，那分析原因就变成了

Android开发测试会经常遇到crash. (1)adb shell (2)cd /data/tombstones/ (3)adb pull /data/tombstones/tombston_00   (保存路径) (4)打开tombstone文件,找到backtrace: backtrace: #00 pc 000239c2  /data/app/com.morpho.cinemagraph-1/lib/arm/libmorpho_cinema_graph.so (mor_cinegrph

转载请注明来源:http://blog.csdn.net/singwhatiwanna/article/details/17289479 前言 大家都知道,android应用不可避免的会发生crash,无论你的程序写的多完美,总是无法完全避免crash的发生,可能是由于android系统底层的bug,也可能是由于不充分的机型适配或者是糟糕的网络状况.当crash发生时,系统会kill掉你的程序,表现就是闪退或者程序已停止运行,这对用户来说是很不友好的,也是开发者所不愿意看到的,更糟糕的是,当用户

今年年底做了很多决定,离开工作三年的深圳,来到了上海,发现深圳和上海在苹果这方面还是差距有点大的,上海的市场8成使用swift编程,而深圳8成的使用OC,这点还是比较让准备来上海打拼的苹果工程师有点小压力的.毕竟以后苹果还是swift使用的多,现在已经swift4.x了,所以早点接触,还是有优势的,不过.咱们闲话少说,今天我们将继续讲述OC修饰属性的一个Weak修饰符的底层实现,有时间我会花时间讲述swift4.x. 一.weak基本用法 weak是弱引用,用weak来修饰.描述所引用对象的计数

转自:http://blog.chinaunix.net/uid-14528823-id-4358785.html Crash工具实战-变量解析 Crash工具用于解析Vmcore文件,Vmcore文件为通过kdump等手段收集的操作系统core dump信息,在不采用压缩的情况下,其相当于整个物理内存的镜像,所以其中包括了最全面.最完整的信息,对于分析定位各种疑难问题有极大的帮助.配置kdump后,在内核panic后,会自动进入kump流程,搜集Vmcore.Crash工具即为专门用于分析vm

转自:https://blog.csdn.net/bytxl/article/details/45025183 前言 Linux 内核(以下简称内核)是一个不与特定进程相关的功能集合,内核的代码很难轻易的在调试器中执行和跟踪.开发者认为,内核如果发生了错误,就不应该继续运 行.因此内核发生错误时,它的行为通常被设定为系统崩溃,机器重启.基于动态存储器的电气特性,机器重启后,上次错误发生时的现场会遭到破坏,这使得查找 内核的错误变得异常困难. 内核社区和一些商业公司为此开发了很多种调试技术和工具,

<< System语言详解 >> 关于 SystemTap 的书. 我们在分析各种系统异常和故障的时候,通常会用到 pstack(jstack) /pldd/ lsof/ tcpdump/ gdb(jdb)/ netstat/vmstat/ mpstat/truss(strace)/iostat/sar/nmon(top)等系列工具,这些工具从某个方面为我们提供了诊断信息.但这些工具常常带有各类“副作用”,比如 truss(见于 AIX/Solaris) 或者 strace(见于

1. 前言 Block:带有自动变量(局部变量)的匿名函数.它是C语言的扩充功能.之所以是拓展,是因为C语言不允许存在这样匿名函数. 1.1 匿名函数 匿名函数是指不带函数名称函数.C语言中,函数是怎样的呢?类似这样: int func(int count); 调用的时候: int result = func(10); func就是它的函数名.也可以通过指针调用函数,看起来没用到函数名: int result = (*funcptr)(10); 实际,在赋值给函数指针时,必须通过函数的名称才能获

转自:http://blog.csdn.net/commsea/article/details/11804897 简介: Linux 内核由于其复杂性,使得对内核出现的各种异常的追踪变得异常困难.本文将介绍内核中的内存转储机制,以及如何使用 crash 工具对内核产生的内存存储文件进行分析.通过对本文的学习,读者可以像专业内核开发者那样去追踪和修复内核的错误.   前言 Linux 内核(以下简称内核)是一个不与特定进程相关的功能集合,内核的代码很难轻易的在调试器中执行和跟踪.开发者认为,内核如

WeTest 导读 北京时间凌晨一点,苹果一年一度的发布会如期而至.新机型的发布又会让适配相关的同学忙上一阵子啦,并且iOS Crash的问题始终伴随着移动开发者.本文将从三个阶段,由浅入深的介绍如何看懂并分析一篇crash报告,一起身临其境去读懂它吧. 孟嵩:这篇万字长文,大概前后翻译了一个月,“写”了三遍:第一遍是直译,第二遍是把直译改成程序员看着舒服的“行话”,第三遍是把原文里说的过于抽象或者简单的部分加上我的注解(大家看见所有以孟嵩开头的部分). 当app发生crash时会产生crash