程序在执行过程中 crash 是非常严重的问题,一般都应该在测试阶段排除掉这些问题,但是总会有漏网之鱼被带到 release 阶段。
https://jackwish.net/2015/introduction-of-google-breakpad.html
Native Crash常常发生在带有Jni代码的APP中,或者系统的Native服务中。作为比较难分析的一类问题,Native Crash其实还是有较多的方法去定位。
本文的目标是帮助大家深入理解Android系统资源异常之文件描述符异常,对于文件描述符异常的通用检测机制,当前包括fdtrack和fdsan两种机制展开剖析。
Backtrace中,一般都只有一些地址。但是利用addr2line这个工具,就可以找到对应的代码行。前提条件是可执行程序或者动态链接库编译的时候带-g选项。
编辑:业余草 来源:https://www.xttblog.com/?p=4946 分享一下,jstack 命令使用经验总结 jstack 在命令使用上十分简洁, 然而其输出的内容却十分丰富, 信息
排查完全陌生的问题、不熟悉的系统组件,对许多工程师来说是无与伦比的工作乐趣,当然也是一大挑战。今天,阿里巴巴售后技术专家声东跟大家分享一例 Kubernetes 集群上的问题。这个问题影响范围较广,或许某天你也会遇到。更重要的是,作者在问题排查过程中的思路和方法,也会让你有所启发。
前几天帮同事跟踪的一个程序莫名退出,没有core dump(当然ulimit是打开的)的问题。我们知道,正常情况下,如果程序因为某种异常条件退出的话,应该会产生core dump,而如果程序正常退出的话,应该是直接或者间接的调用了exit()相关的函数。 基于这个事实,我想到了这样一个办法,在程序开始时,通过系统提供的atexit(),向系统注册一个回调函数,在程序调用exit()退出的时候,这个回调函数就会被调用,然后我们在回调函数中打印出当前的函数调用栈,由此便可以知道exit()是在哪里调用,从而上述
研发人员在遇到线上报警或需要优化系统性能时,常常需要分析程序运行行为和性能瓶颈。Profiling技术是一种在应用运行时收集程序相关信息的动态分析手段,常用的JVM Profiler可以从多个方面对程序进行动态分析,如CPU、Memory、Thread、Classes、GC等,其中CPU Profiling的应用最为广泛。
阿里云有自己的Kubernetes容器集群产品。随着Kubernetes集群出货量的剧增,线上用户零星的发现,集群会非常低概率地出现节点NotReady情况。据我们观察,这个问题差不多每个月,就会有一两个客户遇到。在节点NotReady之后,集群Master没有办法对这个节点做任何控制,比如下发新的Pod,再比如抓取节点上正在运行Pod的实时信息。
本文介绍了JVM平台上CPU Profiler的实现原理,希望能帮助读者在使用类似工具的同时也能清楚其内部的技术实现。
该选项让链接器将所有符号添加到动态符号表中,这样才能将函数地址翻译成函数名,否则打印的结果是不会打印函数名的。
Android OS由3层组成,最底层是Kernel,上面是Native bin/lib,最上层是Java层:
在Linux系统中,程序运行时可能会遇到段错误(Segmentation Fault),这是一种常见的运行时错误,通常由于程序试图访问其内存空间中未分配(或不允许)的部分时发生。
王竞原,负责网游刀锋铁骑项目,高级开发工程师,使用C++已有10年,非常喜欢C++,特别是C++11。希望能与广大的C++爱好者多交流。 一、什么是Android的C/C++ NativeCrash Android上的Crash可以分两种: 1、Java Crash java代码导致jvm退出,弹出“程序已经崩溃”的对话框,最终用户点击关闭后进程退出。 Logcat 会在“AndroidRuntime”tag下输出Java的调用栈。 2、Native Crash 通过NDK,使用C/C++开发,导致
vpp代码中设置捕捉异常信号的函数unix_signal_handler,对一些信号SIGSEGV、SIGABRT、SIGILL等等会打印出异常的调用栈信息,方便我们定位问题。异常调用栈信息可以在系统日志中查询。通常我会使用journalctl -n xxx 来查询日志的打印。
core dump 可以理解为当程序崩溃时,自动将内存信息保存到文件中。这里的 core 就是 memory,dump 就是将内存数据保存到磁盘的过程。
写在前面 Android开发中我们常常会遇到不合理的内存分配导致的问题,或是频繁GC,或是OOM。按照常规的套路我们需要打开Android Studio录制内存分配或者dump内存,然后人工分析,逐个排查问题所在。这些方法是官方提供的能力,可以帮助我们排查问题,但难免有些繁琐,效率比较低。 如果可以自动识别出不合理的Java(含Kotlin)对象分配,这样繁琐的工作将会变得简单。 本文介绍了一种在Art虚拟机上实时记录对象分配的实现方案,基于此方案就可以实现不合理对象分配的自动化的识别。 常规
有时候当你收到一个dump后,大多数情况可以通过k命令查找到导致栈溢出的函数。但是本文要讲的是,曾经碰到过的栈溢出(stackoverflow), 却无法直接通过k命令查看到当前的函数调用栈。 下面将介绍一个简单的方法,找到导致栈溢出的函数。
从第三大点开始讲解ubuntu20.04下无法形成core dump文件的解决办法。
上一篇文章MAT入门到精通(一)介绍了MAT的使用场景和基本概念,这篇文章开始介绍MAT的基本功能,后面还有两篇,一篇是MAT的高级功能,另一篇是MAT实战案例分析。
遇到CPU性能问题时,我们常常通过perf来了解CPU上到底在执行什么,以及通过On-CPU火焰图来帮助我们寻找性能瓶颈。但是,这种方式并不能让我们知道不在CPU上运行的进程和线程到底在做什么。在一些场景中,我们会发现CPU的使用率上不去,性能表现很差,这时候我们也许就需要考虑,是不是花在应用请求、异步调用这种Off-CPU的场景上的时间太多了。
为了帮助开发者开发出更加轻快高效的应用,我们在 Android Studio 3.0 以及更高版本中加入了 Android Profiler 工具,用于应用的 CPU、内存、网络和能耗分析。
摘要:当程序运行出现段错误时,目标文件没有调试符号,也没配置产生 core dump,如何定位到出错的文件和函数,并尽可能提供更详细的一些信息,如参数,代码等。 第一板斧 准备一段测试代码 018.c #include <stdio.h> int main(int argc, char *argv[]) { FILE *fp = NULL; fprintf(fp, "%s\n", "hello"); fclose(fp); return 0; } 编译运行 $ gcc 0
内核死锁问题一般是读写锁(rw_semaphore)和互斥锁(mutex)引起的,本文主要讲如何通过ramdump+crash工具来分析这类死锁问题。
前言 在上一篇《前端魔法堂——异常不仅仅是try/catch》中我们描述出一副异常及如何捕获异常的画像,但仅仅如此而已。试想一下,我们穷尽一切捕获异常实例,然后仅仅为告诉用户,运维和开发人员页面报了一个哪个哪个类型的错误吗?答案是否定的。我们的目的是收集刚刚足够的现场证据,好让我们能马上重现问题,快速修复,提供更优质的用户体验。那么问题就落在“收集足够的现场证据”,那么我们又需要哪些现场证据呢?那就是异常信息,调用栈和栈帧局部状态。(异常信息我们已经获取了) 本文将围绕上调用栈和栈帧局部状态叙述,准开
小木在对代码进行测试的时候,发现进程占用了100%的单核CPU资源。并且发现在另一个环境,这个进程占用了12%的CPU资源,因为在这个环境中是8核的CPU。而此时这个进程还并没有处理任何的数据,也就是说会有一个线程就占用一个CPU核的资源。
Heap Dump 概述 Heap Dump 是 Java进程所使用的内存情况在某一时间的一次快照。以文件的形式持久化到磁盘中。 Heap Dump的格式有很多种,而且不同的格式包含的信息也可能不一样。但总的来说,Heap Dump一般都包含了一个堆中的Java Objects, Class等基本信息。同时,当你在执行一个转储操作时,往往会触发一次GC,所以你转储得到的文件里包含的信息通常是有效的内容(包含比较少,或没有垃圾对象了) 。 Heap Dump 包含的信息 所有的对象信息 对象的类信息、字段
最近给服务器提供协议编解码库,出现较多内存相关的问题,做个记录,顺便给有相同需求的同学提供参考!
工具的进化一直是人类生产力进步的标志,合理使用工具能大大提高我们的工作效率,遇到问题时,合理使用工具更能加快问题排查的进度。这也是我为什么非常喜欢 shell 的原因,它丰富的命令行工具集加管道特性处理起文本数据集来真的精准而优雅,让人迷醉。
工具的进化一直是人类生产力进步的标志,合理使用工具能大大提高我们的工作效率,遇到问题时,合理使用工具更能加快问题排查的进度。这也是我为什么非常喜欢 shell 的原因,它丰富的命令行工具集加管道特性处理起文本数据集来真的精准而优雅,让人迷醉。超牛逼!100 个开箱即用的 Shell 脚本,拿好了~
曾经碰到一种奇怪的Crash场景:Windows程序Crash,每次用windbg attach或者ntsd/cdb产生dump,总是不能捕获到程序出错时候的栈,而且crash的时候只能看到少数甚至只剩一个线程的信息,而这个仅有的一些线程函数调用栈,也并不是导致程序Crash的地方。
最近在分析golang的一个内存泄漏问题。一般来讲,使用golang自带的pprof工具就可以分析内存的使用,协程情况,是否有block等情况。但是我们项目中调用了C库,导致C库的一些东西没法通过pprof来进行监控分析。实际上通过pprof来监控程序的话,内存是稳定的,但是占用Linux的内存是一直增长的,即RES一直增长,实际上程序是有泄漏的。怀疑是使用C库导致,所以通过coredump文件来进行分析。下面主要介绍golang coredump的使用。
继上周介绍了稳定性三大故障之一的ANR类故障后,本章继续介绍第二大类故障Crash/Tombstone及其分析定位方法。
在项目中遇到一个问题,我们服务提供给外部的一个接口 queryXXX 一直返回 429 错误(Too Many Requests),接口没有返回值,而且服务越用越卡,要重启一下才能恢复。于是马上就想到是不是因为这个接口产生了死循环,导致接口无法正确返回,同时导致后台 CPU 和内存占用飙升,顺着这个思路定位下去,确实顺利的找到的问题所在。
输出变量的数据值,特别是数组和对象数据,一半在查看接口的返回值或者不确定的变量可以使用这两个api,debug_zval_dump输出结果和var_dump类似,位移增加的值是refcount,记录一个变量被引用了多少次
不必太纠结于当下,也不必太忧虑未来,当你经历过一些事情的时候,眼前的风景已经和从前不一样了。——村上春树
Windows中内存泄露的文章本人已经写过两篇<<Windows程序内存泄漏(Memory Leak)分析之UMDH>>和<<Windows程序内存泄漏(Memory Leak)分析之Windbg>>。如果有丰富调试经验的同学会发现,很难用一种工具或者方法去分析所有的场景,尤其当工程庞大的时候。本文要介绍的就是微软提供的DebugDialog, 他可以用于分析Hang,性能问题,内存泄露问题等等。对于内存泄露问题,DebugDialog分析后会给出一个完整的Report,免去了你通过Windbg命令去分析内存的过程,适合于新人。
我们在项目开发过程中,很多时候会出现由于某种原因经常会导致手机系统死机重启的情况(重启分Android重启跟kernel重启,而我们这里只讨论kernel重启也就是 kernel panic 的情况),死机重启基本算是影响最严重的系统问题了,有稳定复现的,也有概率出现的,解题难度也千差万别,出现问题后,通常我们会拿到类似这样的kernel log信息(下面log仅以调用BUG()为例,其它异常所致的死机log信息会有一些不同之处):
熟悉高通平台的童鞋可能会比较熟悉,高通有ramdump功能,当系统crash后通过warm reset重启来抓取ram中的数据,然后利用Trace32进行故障现场的查看来排查问题。这实际上用到的就是trace32的simulator功能,也就是仿真器功能,我们只需要获取到设备的内存快照来进行指令集的仿真,以此查看故障现场,而不用真实的连接目标板来实时调试。
根据当前帧的eip(x86)来调用 CodeModules::GetModuleForAddress()返回当前frame所属的模块信息
日常的工作中,会收到一堆CPU使用率过高的告警邮件,遇到某台服务的CPU被占满了,这时候我们就要去查看是什么进程将服务器的CPU资源占用满了。通常我们会通过top或者htop来快速的查看占据CPU最高的那个进程,如下图:
一般来说,项目开发过程中,代码编写占开发总时间的40%,剩下的时间基本就是自测和联调的过程。程序出错很正常,关键是如何迅速的去定位它,修掉它。本文将介绍自己程序调试的一些常用方法,这边我以golang为例,总结为望问切闻---debug四部曲。
编写代码只是程序员的工作之一,调试代码的时间甚至会超过编写代码,之前为大家讲解了很多关于系统、架构、编程等方面的内容,这篇文章就为大家全方位展示一次涉及到内核的 bug 排查过程。
kprobe机制用于在内核中动态添加一些探测点,可以满足一些调试需求。本文主要探寻kprobe的执行路径,也就是说如何trap到kprobe,以及如何回到原路径继续执行。
领取专属 10元无门槛券
手把手带您无忧上云