Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
网上看到一个很有意思的美团面试题：为什么线程崩溃崩溃不会导致 JVM 崩溃，这个问题我看了不少回答，但发现都没答到根上，所以决定答一答，相信大家看完肯定会有收获，本文分以下几节来探讨
下面是一份crash report, 下面是截取了crash report的部分，用于分析：
每一个 JVM 线程都拥有一个私有的 JVM 线程栈，用于存放当前线程的 JVM 栈帧（包括被调用函数的参数、局部变量和返回地址等）。如果某个线程的线程栈空间被耗尽，没有足够资源分配给新创建的栈帧，就会抛出 java.lang.StackOverflowError 错误。
当jvm出现致命错误时，会生成一个错误文件 hs_err_pid<pid>.log，其中包括了导致jvm crash的重要信息，可以通过分析该文件定位到导致crash的根源，从而改善以保证系统稳定。当出现crash时，该文件默认会生成到工作目录下，然而可以通过jvm参数指定生成路径（JDK6中引入）： -XX:ErrorFile=./hs_err_pid<pid>.log 该文件包含如下几类关键信息： 日志头文件 导致crash的线程信息 所有线程信息 安全点和锁信息 堆信息 本地代码缓存 编译事件 g
当jvm出现致命错误时，会生成一个错误文件 hs_err_pid<pid>.log，其中包括了导致jvm crash的重要信息，可以通过分析该文件定位到导致crash的根源，从而改善以保证系统稳定。当出现crash时，该文件默认会生成到工作目录下，然而可以通过jvm参数指定生成路径（JDK6中引入）：
1. 概况 程序运行操作系统： CentOS6.5 64bit JDK版本：7 2. 测试 2.1 准备测试程序 测试程序很简单，就一个类一个main函数，大概流程： 先从参数中读取 获取zip文件的时间间隔interval，再从参数中获取zip文件路径。再通过ZipFile类的api来从zip文件中获取文件的全路径名。每次获取一个文件sleep interval时间，便于测试。 代码如下： /** * Usage： App <interval in ms to
本文介绍Java诸多优化实例：第一，排查堆上、堆外内存泄露；第二，使用arthas、jaeger、tcpdump、jstack做性能优化；第三，排查进程异常退出的原因，如被杀、System.exit、Java调用的C++发生Crash、Java内Crash；第四，排查死锁的原因，如log4j死锁、封装不严谨导致的死锁
导读 本文介绍Java诸多优化实例：第一，排查堆上、堆外内存泄露；第二，使用arthas、jaeger、tcpdump、jstack做性能优化；第三，排查进程异常退出的原因，如被杀、System.exit、Java调用的C++发生Crash、Java内Crash；第四，排查死锁的原因，如log4j死锁、封装不严谨导致的死锁 内存泄漏 内存泄露在C++里排查很简单，用钩子函数勾住内存分配和释放函数malloc和free，统计哪些malloc的内存没有free，就可以找出内存泄露的源头。但在Java
背景描述 某项目结构图如下(前端交互式体验及对象存储为主，Redis 及 rds 负载较小没有画出)： web1 和 web2 是两个 Apache，publisher1 和 publisher2 是
JPDA 全称 Java Platform Debugger Architecture. 是Java定义的标准调试框架。
王竞原，负责网游刀锋铁骑项目，高级开发工程师，使用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++开发，导致
一、背景 在Android平台，native crash一直是crash里的大头。native crash具有上下文不全、出错信息模糊、难以捕捉等特点，比java crash更难修复。所以一个合格的异常捕获组件也要能达到以下目的： 支持在crash时进行更多扩展操作，如： 打印logcat和应用日志 上报crash次数 对不同的crash做不同的恢复措施 可以针对业务不断改进和适应 二、现有的方案 其实3个方案在Android平台的实现原理都是基本一致的，综合考虑，可以基于coffeecatch改进。
我们知道，Java程序的运行需要一个运行时环境，即：JVM，启动Java进程即启动了一个JVM。 因此，所谓停止Java进程，本质上就是关闭JVM。 那么，哪些情况会导致JVM关闭呢？
折腾了两天总算搞定c调用jar包，其中遇到的问题这里总结一下： 1、起始demo 参考C调用java例子先跑起来 2、开发环境 使用linux虚拟机效率很低，找到了gnuwin32实现在windows下运行Makefile，使用的是https://sourceforge.net/projects/gnuwin32/ ，只需要把 mingw32-make.exe文件改名为make.exe 3、java开发 直接使用eclipse生成一个mvn项目，以这个最简项目开始入手 使用mvn编译出jar给c调用，参考maven将所有的依赖打成一个包，确保依赖没有问题，验证方法：
Tomcat经常崩溃crash，想看看JVM内存使用情况，就想到了用Jconsole监控，以前只是监控本地的JVM，这次要监控远程的，遇到了不少问题。
在Android代码中，加载so库是通过调用System.loadLibrary函数实现的。但和Android的许多特性一样，只提供了加载，而没有卸载和更换等功能。为了研究能否实现卸载和升级等功能，首先要了解清楚JNI so加载的流程。
NDK即Native Development Kit，是Android上用来开发c/c++的开发工具包。 安装步骤：developer.android.com/studio/proj…
解决每一类问题都需要消耗大量的时间，特别是重新编译内核这种事情。于是，每一个Linux内核程序员或多或少都会掌握一些Hack技巧，以节省时间提高工作效率。
1、根目录下的bin和sbin，usr目录下的bin和sbin，这四个目录都是用来保存系统命令的。 2、bin目录下的命令时任何用户都能执行，sbin目录下的命令只有超级用户才能执行。 3、media用来挂载光盘，misc挂载磁带机，mnt挂载U盘。它们都是空目录。 4、proc和sys目录不能直接操作，这两个目录保存的是内存挂载点。 5、可以在家目录root或home，以及tmp目录下随便放内容。
Linux操作系统在作为服务器的场景下应用最为广泛,但是在使用过程中也会遇到莫名崩溃的情况.这时我们就希望能对崩溃前一刻内存中的数据进行分析,从而找到崩溃的原因.本文将对整个过程所涉及到的技术做一个简单但是全面的介绍,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux运维人员更快更方便地排查问题.
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具，掌握 crash 的使用技巧，对于分析定位内核崩溃的问题，有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法，其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件，包括各种常用调试命令的使用方法，最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中，既有详细的工具使用方法，又有丰富的实际案例分析，相信您读过以后定会受益匪浅。
_NullPointer 出处：https://www.cnblogs.com/renwei/
在启动一个Springboot工程时，抛出一项“Cannot allocate memory”异常，很明显，是因为内存分配原因导致的OOM异常导致JVM宕掉。跟随log，查看JVM hs_err_pid24442.log文件。
大家好，我是腾讯Bugly的精神哥（英文名：spirit），是Bugly资深码奴的同时，又是Bugly神秘的Crash实验室研究员哦！我的主要任务就是泡在实验室里，嗑着瓜子嚼着鸡爪，研究移动App中各种Crash（专挑疑难、坑爹、时髦、有趣的Crash），并通过“精神哥讲Crash”系列定期分享给大家！ 今天精神哥给大家分享的第一个Crash是“UnsatisfiedLinkError” 。 一、UnsatisfiedLinkError基本介绍 全名java.lang.UnsatisfiedLinkErro
今天讲的是纯干货，目的就是为了指导Android开发者如何根据JNI Crash日志顺藤摸瓜，最后直捣黄龙定位磨人的JNI Crash。所以废话不多，直接开干吧。
之前的文章JVM 如何处理未捕获异常 我们介绍了JVM如何处理未捕获异常，今天我们研究一个更加有意思的问题，就是在JVM中如果发生了未捕获异常，会导致JVM进程退出么。
作者简介 刘韬，云和恩墨中间件服务交付团队专家 Java开发出身，10年WebLogic相关开发、运维工作经验，熟悉SOA、现代业务系统架构中各层组件，尤其擅长故障处理、性能优化等工作。 故障案例一 系统环境： RHEL 6.8 64-bit（glibc 2.12）、Sun JDK 6u45 64-bit、WLS 10.3.6 故障现象： 这里引用一下客户当时发邮件时提出的问题描述吧。 下面pid 6287 weblogic进程占用7.6G的物理内存，之前只占用5G内存。我发现只有系统有空余的内存，就会被j
在运维的世界里，服务器的稳定运行是生命的灯塔，一旦遭遇异常重启，便是暴风雨来临的预兆。作为一名运维工程师，深知在这场与故障斗争的战役中，武器的锋利至关重要。今天，我要介绍的主角/工具——kdump，正是这样一款能在风雨来临之际，为我们捕获那一闪而过的真相的工具。
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers，Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是，依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题，这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
前言： GuestOS中如果发生了一些错误，GuestOS还活着，shell已经hung住了，如何获取到GuestOS中的关键log信息呢？ 分析： 1，keyboard interrupt QE
线上某个kafka集群由于种种原因，从 24 * 机型 A 置换迁移为 12 * 机型 B。从集群总资源维度看，排除其他客观因素，置换后，CPU总核数少了一半，使用率上升其实也是预期之内的。事实上置换后，集群CPU使用率确实也由原有的 20%提升至 40%，上升了约 1 倍多。但置换后，cpu sys使用率均值约达到了 12%，较为抢眼，系统相关服务却并无异常，令人有些困惑。
在完成了产品的基础开发以后，接下来需要进行一些周边的工作，这些周边工具将会帮助下一步优化产品。
mv linux-image-4.15.0-118-generic-dbgsym_4.15.0-118.119_amd64.ddeb linux-image-4.15.0-118-generic-dbgsym_4.15.0-118.119_amd64.deb
我的操作系统是Red Hat Enterprise Linux Server release 6.6 (Santiago)，这也是我们目前生产上用的。 我直接在root下安装，先切换到root用户。 首先，安装下需要的软件，Riak官网给的不全：
breakpad是一组用于实现崩溃报告系统的客户端和服务器组件。Chromium的Breakpad是目前Native崩溃捕获中最成熟的方案。它是一套完整的工具集，从Crash的捕获到Crash的dump，都提供了相对应的工具。它记录了崩溃时的.dump文件，无论我们是在本地或者发送到服务器端，都可以用相对应的工具来解析.dump文件帮助我们查找C和C++堆栈踪迹。
我们知道Java崩溃是在Java代码中出现了未捕获异常，导致程序异常退出，常见的异常有：NPE、OOM、ArrayIndexOutOfBoundsException、IllegalStateException、ConcurrentModificationException等等。 还有一类崩溃，也是我们不得不关注，那就是Native层崩溃，这类崩溃不像Java层崩溃那样比较清晰的看出堆栈信息以及具体的崩溃。每当遇到是都要查找分析，写这篇的目的是帮助自己做下记录，也希望能帮到有类似困扰的你，下面我们开始一起学习实践吧。 本文学习实践的demo以张绍文《Android开发高手课》中的例子进行。
在Android NDK开发中，Native层的崩溃信息不像Java层的崩溃堆栈那样可以直接看到出现问题的函数名和行数
本文主要介绍kdump服务和crash的使用，并结合一个简单的实例演示如何分析内核奔溃的原因。本文基于linux kernel 4.19, 体系结构为aarch64。 kdump概述 kdump kdump 是一种先进的基于 kexec 的内核崩溃转储机制，用来捕获kernel crash（内核崩溃）的时候产生的crash dump。当内核产生错误时，kdump会将内存导出为vmcore保存到磁盘。 kdump流程 当系统崩溃时，kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以
Native Crash常常发生在带有Jni代码的APP中，或者系统的Native服务中。作为比较难分析的一类问题，Native Crash其实还是有较多的方法去定位。
前言 小巫最近由于工作原因面临技术转型，从一个App开发者转变为SDK开发者，这两者的区别是非常明显的，从用户角度来讲，app开发主要面向普通的用户需求，然而SDK开发面向的却是开发人员；从技术角度来讲，app开发更多的只是UI层面、基于数据流的技术实现，而SDK开发可能就要涉及更多复杂的需求、更多底层相关的技术实现。前面我在公众号分享了一篇文章：一个好的SDK或好的开放平台应该为开发者提供什么？，大家有兴趣可以看看。本系列博文主要是想跟大家分享一下在Android平台中如何进行Crash分析并解决问题并告
目录介绍 01.该库具有的功能 02.该库优势分析 03.该库如何使用 04.降低非必要crash 05.异常恢复原理 06.后续的需求说明 07.异常栈轨迹原理 08.部分问题反馈 09.其他内容说明 01.该库具有的功能 1.1 功能说明 异常崩溃后思考的一些问题 1.是否需要恢复activity栈，以及所在崩溃页面数据 2.crash信息保存和异常捕获，是否和百度bug崩溃统计sdk等兼容。是否方便接入 3.是否要回到栈顶部的那个activity(保存栈信息) 4.崩溃后需要收集哪些信息。手机信息，a
在 Android NDK 开发中，排查问题遇到的最熟悉的关键字非 backtrace 莫属，Linux 系统中进程 crash 后通过 backtrace 输出堆栈信息，开发者就是基于这些堆栈信息来定位代码问题。
counter = -2 //初始值为1，每增加一个等锁的进程则减1，-2代表当前有两个进程（不含已获取锁进程）正在等待该mutex锁。
https://time.geekbang.org/column/article/70602
2）获取对应软件版本的符号表文件（如vmlinux），可以将该文件放置 crash工具同一目录下。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
