Native Crash常常发生在带有Jni代码的APP中，或者系统的Native服务中。作为比较难分析的一类问题，Native Crash其实还是有较多的方法去定位。
本文旨在介绍下几种常见的调试方法gdb、crash、kgdb and kdb 以及dynamic debug. 关于在 Linux 内核上使用debuggers，Linus Torvalds 长期以来对它们不太喜欢。简短地解释这种态度是，依赖调试器可能鼓励用权宜之计而非深思熟虑来解决问题，这会导致代码质量恶化。详细解释可以参考https://lwn.net/2000/0914/a/lt-debugger.php3
https://whereisk0shl.top/post/2016-10-23-1
crash 是目前广泛使用的 linux 内核崩溃转储文件的分析工具，掌握 crash 的使用技巧，对于分析定位内核崩溃的问题，有着非常重要的作用。本文首先介绍了 crash 的基本概念和安装方法，其次详细介绍了如何使用 crash 工具分析内核崩溃转储文件，包括各种常用调试命令的使用方法，最后以几个实际工作中遇到的真实案例向读者展示了 crash 的强大功能。在这篇文章中，既有详细的工具使用方法，又有丰富的实际案例分析，相信您读过以后定会受益匪浅。
2）获取对应软件版本的符号表文件（如vmlinux），可以将该文件放置 crash工具同一目录下。
Linux操作系统在作为服务器的场景下应用最为广泛,但是在使用过程中也会遇到莫名崩溃的情况.这时我们就希望能对崩溃前一刻内存中的数据进行分析,从而找到崩溃的原因.本文将对整个过程所涉及到的技术做一个简单但是全面的介绍,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux运维人员更快更方便地排查问题.
最近在分析golang的一个内存泄漏问题。一般来讲，使用golang自带的pprof工具就可以分析内存的使用，协程情况，是否有block等情况。但是我们项目中调用了C库，导致C库的一些东西没法通过pprof来进行监控分析。实际上通过pprof来监控程序的话，内存是稳定的，但是占用Linux的内存是一直增长的，即RES一直增长，实际上程序是有泄漏的。怀疑是使用C库导致，所以通过coredump文件来进行分析。下面主要介绍golang coredump的使用。
解决每一类问题都需要消耗大量的时间，特别是重新编译内核这种事情。于是，每一个Linux内核程序员或多或少都会掌握一些Hack技巧，以节省时间提高工作效率。
这些工具可以帮助开发人员深入了解程序崩溃时的状态，并帮助他们诊断和解决问题。 详细内容可以参考下面的官方文档： Core Analyzer Home (sourceforge.net)
[1] r3kapig HITCON CTF 2019 Writeup https://r3kapig.com/writeup/20191018-hitcon-quals/
昨晚程序又出现buffer泄漏了，导致业务中断了，采集了一下基本的信息及手动生成vpp的core文件，就重启了程序。
前言：说真的Android NDK debug还是推荐lldb，gdb经常莫名其妙的不成功。不过下面的这个流程是谷歌官方建议的，还是有参考价值的。尤其是在App启动时Debug的流程。
GDBFuzz是一款功能强大的模糊测试工具，在该工具的帮助下，广大研究人员可以使用硬件断点对嵌入式系统进行模糊测试。
Apache Doris的BE部分是由C++编写，当出现一些内存越界，非法访问的问题时会导致BE进程的Crash。这部分的问题常常较难排查，同时也很难快速定位到对应的触发SQL，给使用者带来较大的困扰。所以下面会介绍通过Linux的CoreDump快速定位到问题SQL，并复现问题的方式。
GDB（GNU Debugger）是Linux上的调试程序，可用于C/C++、Go、Rust等多种语言。GDB可以让你在被调试程序执行时看到它的”内部“情况，观察程序在特定断点上的状态，并逐行运行代码。
最近在测试一些大数据量的HashJoin计算，例如：用户层设置batch数为600000，那么会导致crash。本节将会通过调试，来一步步学习SwissJoin(HashJoin的内部实现)的分区逻辑。
The source code of the software we use on a daily basis isn’t always available. A disassembler like IDA Pro is capable of creating maps of their execution to show the binary instructions that are actually executed by the processor in a symbolic representation called assembly language. This disassembly process allows software specialists to analyse programs that are suspected to be nefarious in nature, such as spyware or malware. However, assembly language is hard to read and make sense of. That is why advanced techniques have been implemented into IDA Pro to make that complex code more readable. In some cases, it is possible to revert the binary program back, to a quite close level, to the original source code that produced it. The map of the program’s code can then be post-processed for further investigation.
情况是这样的，有一套测试数据库所在的主机在最近几个月，每个月都会重启一至两次，由于数据库配置了开机自启动，且每次重启时间都比较短暂，便没有得到重视。最近由于测试人员的反馈，每当主机重启后呢会导致大片的测试应用由于断连导致无法使用，每次都需要重启应用才会好。那么我们就需要介入认真排查一下问题所在了，恰巧最近一次的重启时间为 11 月 10 日 18:29 左右，需要针对此问题分析 os 重启原因。
当医生遇到疑难杂症时，那么可以上 X 光机，有没有病？病在哪里？一照便知！当程序员遇到疑难杂症时，那么多半会查日志，不过日志的位置都是预埋的，可故障的位置却总是随机的，很多时候当我们查到关键的地方时却总是发现没有日志，此时就无能为力了，如果改代码加日志重新发布的话，那么故障往往就不能稳定复现了。回想医生的例子，他们可没有给病人加日志，可为什么他们能找到问题的，因为他们有 X 光机，所以对程序员来说，我们也需要有我们的 X 光机，它就是 eBPF。
对用户态进程，利用gdb调试代码是很方便的手段。而对于内核态的问题，可以利用crash等工具基于coredump文件进行调试。
Rex是由Shellphish开发的自动化漏洞利用引擎，设计初衷在于参加Cyber Grand Challenge。本文以栈溢出为例，展示Rex自动生成 Exploit的能力。测试样例为Linux下可执行程序vuln_stacksmash，其中存在栈溢出漏洞，通过Rex自动生成rop2system、rop2text、jmpesp三种Exploit。
Windows无人参与安装在初始安装期间使用应答文件进行处理。您可以使用应答文件在安装过程中自动执行任务，例如配置桌面背景、设置本地审核、配置驱动器分区或设置本地管理员账户密码。应答文件是使用Windows系统映像管理器创建的，它是Windows评估和部署工具包（ADK：Assessment and Deployment Kit）的一部分，可以从以下站点免费下载https://www.microsoft.com.映像管理器将允许您保存unattended.xml文件，并允许您使用新的应答文件重新打包安装映像（用于安装Windows）。在渗透式测试期间，您可能会在网络文件共享或本地管理员工作站上遇到应答文件，这些文件可能有助于进一步利用环境。如果攻击者遇到这些文件，以及对生成映像的主机的本地管理员访问权限，则攻击者可以更新应答文件以在系统上创建新的本地账户或服务，并重新打包安装文件，以便将来使用映像时，新系统可以受到远程攻击。
作者简介：黄权隆，Cloudera研发工程师，Apache Impala PMC & Comitter，毕业于北大计算机系网络所数据库实验室，曾就职于Hulu大数据基础架构团队，负责大数据系统的维护和二次开发，主要负责Impala和HBase方向。现就职于Cloudera，专注于Impala开发。
前言： 进程crash一般比较讨厌，尤其是segmentation fault，所谓的“踩内存”，是最讨厌的。 分析： 1，status 进程的状态，一般使用ps aux命令查看： 其中STAT列
说复杂倒也不复杂，但是我想在重现的时候下载了redis的源码，编译什么的折腾了一遍。
前言： qemu发生了crash。这种类型的问题比较少见，这里说一下这个问题的分析过程。 分析： 1，coredump 生成的coredump，一种是配置了/proc/sys/kernel/cor
GreatSQL合并Percona-Server 8.0.30的Beta版测试中，QA报了一个crash的bug：
因为 backtrace 信息不完整，说明程序并不是在第一时间 crash 的。面对这种情况，为了快速找出第一现场，我们可以试试 AddressSanitizer（ASan）：
客户给了一些 C语言 写的 SDK 库，这些库打包成 .so 文件，然后我们使用 C# 调用这些库，其中有一个函数是回调函数，参数是结构体，结构体的成员是函数，将 C# 的函数赋值给委托，然后存储到这个委托中。
某业务 MySQL 实例（MySQL 5.7.20 社区版）发生 Crash，现需要对其具体原因进行分析。
安装mac的虚拟机已经很长一段时间了，但是由于总是出现五国语言，导致也没什么兴致折腾这个鸟东西。从网上搜索了一些解决方案，但是基本没什么鸟用。后来不经意发现一个哥们说在安装过程中频繁出现五国语言，只需要将处理器设置为单核心就行了。于是我就想启动之后的五国语言是不是也可以这么搞？于是就试了一下发现果然不死机了。nngx，太神奇鸟。
程序运行过程中可能会异常终止或崩溃，OS会把程序挂掉时的内存状态记录下来，写入core文件，这就叫 coredump，通过gdb结合core文件可以方便地进行调试。
我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21)，不定期的会crash，但error log中只记录了重启信息，未记录crash时的堆栈：
在 Android NDK 开发中，排查问题遇到的最熟悉的关键字非 backtrace 莫属，Linux 系统中进程 crash 后通过 backtrace 输出堆栈信息，开发者就是基于这些堆栈信息来定位代码问题。
Netgear R6400 多个固件版本中的upnpd存在栈溢出漏洞(CVE-2020-9373)，通过向其udp 1900端口发送构造的ssdp数据包，可能导致DOS或RCE。下文的测试均使用V1.0.1.52_1.0.36这本版本的固件包。
一般来说，项目开发过程中，代码编写占开发总时间的40%，剩下的时间基本就是自测和联调的过程。程序出错很正常，关键是如何迅速的去定位它，修掉它。本文将介绍自己程序调试的一些常用方法，这边我以golang为例，总结为望问切闻---debug四部曲。
在 NDK 开发中，排查问题遇到的最熟悉的关键字非 backtrace 莫属，Linux 系统中进程 crash 后通过 backtrace 输出堆栈信息，开发者就是基于这些堆栈信息来定位代码问题。当然定位 Native 层代码问题最优的方式还是通过 IDE（AS、VS）或者 GDB 进行 debug 断点调试，本文针对的是使用第三方 C/C++ SDK 出现 crash 的场景。
在Linux平台，自研服务进程通常以守护进程的形式在后台常驻运行。但偶尔也会遇到服务进程异常crash，导致产品基本功能异常，影响恶劣。 解决这种问题，通常两种应对措施： ① 定位crash原因，上传补救措施。 ② 后台重新拉起异常进程，避免影响基本功能。 对于措施①，系统部署coredump文件，通过gdb解析coredump文件就能很快定位到原因，本篇主要记录下措施②实现流程。
本文介绍Java诸多优化实例：第一，排查堆上、堆外内存泄露；第二，使用arthas、jaeger、tcpdump、jstack做性能优化；第三，排查进程异常退出的原因，如被杀、System.exit、Java调用的C++发生Crash、Java内Crash；第四，排查死锁的原因，如log4j死锁、封装不严谨导致的死锁
作者简介：中年码农，做过电信、手机、安全、芯片等行业，靠Linux混饭吃。 简介 Kdump 提供了一种机制在内核出现故障的时候把系统的所有内存信息和寄存器信息 dump 出来成一个文件，后续通过 gdb/crash 等工具进行分析和调试。和用户态程序的 coredump 机制类似。它的主要流程如下图所示： 可以看到它的核心原理是保留一段内存并且预先加载了一个备用的 kernel，在主 kernel 出现故障时跳转到备用 kernel，在备用 kernel 中把主 kernel 使用的内存和发生故障时的寄
打算为入门ARM指令集写点初级文章，没什么远大理想，写到哪里算哪里，权当娱乐罢了。工作中经常碰到crash的问题，如果是debug版本，那还好， 调试信息多。万一Release给QA甚至客户之后，再发现crash之类的问题，要不熟悉ARM指令、看不懂现场那就麻烦了。 环境准备：现在的学习环境可真是方便啊，几乎人手一台android手机，而绝大多数手机都是ARM家族的，所以只需要给手机或者平板电脑安装一个 BusyBox，然后拷贝一个ARM 的gdb，再安装一个GCC就可以了。 好
对crash的数据库进行故障分析并不是一件快乐的事情，尤其是 MySQL 的日志中没有提供 crash 原因的情形。比如当 MySQL 内存耗尽。在 2012年 Peter Zaitsev 写了一篇文章 分析MySQL如何使用内存
导读 本文介绍Java诸多优化实例：第一，排查堆上、堆外内存泄露；第二，使用arthas、jaeger、tcpdump、jstack做性能优化；第三，排查进程异常退出的原因，如被杀、System.exit、Java调用的C++发生Crash、Java内Crash；第四，排查死锁的原因，如log4j死锁、封装不严谨导致的死锁 内存泄漏 内存泄露在C++里排查很简单，用钩子函数勾住内存分配和释放函数malloc和free，统计哪些malloc的内存没有free，就可以找出内存泄露的源头。但在Java
Linux常用命令中有一些命令可以在开发或调试过程中起到很好的帮助作用，有些可以帮助了解或优化我们的程序，有些可以帮我们定位疑难问题。本文将简单介绍一下这些命令。
Oh, My God! 是死锁问题。尽管报错不多，对性能目前看来也无太大影响，但还是需要解决，保不齐哪天成为性能瓶颈。
因为我现在的系统是MacOS Catania，是在 Mojave (10.14) 之后的系统。所以还需要创建一个配置文件gdb-entitlement.xml，其内容如下：
下面是一份crash report, 下面是截取了crash report的部分，用于分析：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
