王竞原,负责网游刀锋铁骑项目,高级开发工程师,使用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++开发,导致
SIGSEGV,也称为分段违规或分段错误,是基于 Unix 的操作系统(如 Linux)使用的信号。它表示程序尝试在其分配的内存之外进行写入或读取,由于编程错误、软件或硬件兼容性问题或恶意攻击(例如缓冲区溢出)。
信号是由操作系统传给进程的中断,会提早终止一个程序。在 UNIX、LINUX、Mac OS X 或 Windows 系统上,可以通过按 Ctrl+C 产生中断。
在使用C或C++编写程序时,有时会遇到一些运行时错误,其中一种常见的错误是Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0。这个错误提示意味着程序引发了一个严重的信号(Signal),导致程序崩溃。SIGSEGV是段错误(Segmentation Fault)的信号,它通常发生在访问无效的内存地址时。
问: Segmentation fault 可以用程序被捕获吗? 答:不能防不胜防: 换个问题:谈谈你段错误理解, 如果是回答 core,非法地址, 说明还是处于青铜阶段,这是定义, 根本不知道背
我们经常会使用 kill 命令杀掉运行中的进程,对多次杀不死的进程进一步用 kill -9 干掉它。你可能知道这是在用 kill 命令向进程发送信号,优雅或粗暴的让进程退出。我们能向进程发送很多类型的信号,其中一些常见的信号 SIGINT 、SIGQUIT、 SIGTERM 和 SIGKILL 都是通知进程退出,但它们有什么区别呢?很多人经常把它们搞混,这篇文章会让你了解 Linux 的信号机制,以及一些常见信号的作用。
Google breakpad是一个跨平台的崩溃转储和分析框架和工具集合。 Breakpad由三个主要组件:
版权声明:本文为博主原创文章,转载请注明源地址。 https://blog.csdn.net/10km/article/details/82895874
c++ 标准库 sort() 默认采用 < 这个 operator 来排序的, 另个一个重载函数增加第三个参数,指定一个比较的函数,函数接受两个参数。 对于基础类型(int,float..),直接调用 sort(start,end) 即可,对于非基础类型的结构体,可以通过重载对象的 < 运算符或者提供一个比较函数。 详见
有什么好的办法可以在 C/C++ 程序段错误退出时输出堆栈信息,来方便查找错误么?
现在大部分应用都会有Java层的崩溃日志收集机制,一般就是程序crash后,展示一个上报界面,用户点击就上传了。 但是Native程序crash了,很少有做处理的,几个方面原因:
因为 backtrace 信息不完整,说明程序并不是在第一时间 crash 的。面对这种情况,为了快速找出第一现场,我们可以试试 AddressSanitizer(ASan):
应用层的异常,未被捕获的异常,导致程序向自身发送了 SIGABRT 信号而崩溃,是应用程序自己可控的。对于未被捕获的异常,是可以通过 try-catch 或 NSSetUncaughtExceptionHandler() 机制类捕获的。
断点异常类型表示跟踪陷阱(trace trap)中断了该进程。跟踪陷阱使附加的调试器有机会在进程执行的特定点中断进程。 在 ARM 处理器上显示为 EXC_BREAKPOINT(SIGTRAP) 在 x86_64 处理器上显示为 EXC_BAD_INSTRUCTION(SIGILL)
Linux内核实现了一批优雅而功能强大的双向循环列表操作宏,它们位于/usr/include/linux/list.h(请注意直接#include会报编译错误),这些宏可以直接扣出来,在需要时使用。
SIGINT的默认处理动作是终止进程,SIGQUIT的默认处理动作是终止进程并且Core Dump,我们来验证一下
OpenJDK原是Sun MicroSystems公司(下面简称Sun公司)为Java平台构建的Java开发环境,于2009年4月15日由Sun公司正式发布。后来Oracle公司在2010年收购Sun公司,接管了这项工作。
我国信创生态的核心企业龙芯,其自主知识产权的 LoongArch指令集核心 maintainer 在 Linux 内核邮件列表了总结了他们近期对内核的贡献。
生产环境定位问题往往遇到各种限制,比如事后日志发现程序是收到SIGSEGV退出了(segment fault),但是因为:
在移动应用开发中,我们经常会遇到各种错误和异常。其中一个常见的错误是 cn.sample.mnn.detect A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid。这个错误通常与内存访问相关,并且是一个严重的错误,可能导致应用崩溃。
Yaf框架是一个c语言编写的PHP框架,它更快、更轻、内存占用更低。项目组本着对性能的追求选择了Yaf框架,由于安全的原因PHP升级到7.3.18,为了兼容PHP,将Yaf升级到3.2.3。Yaf框架的bug导致PHP进程core。尽管从表象上看就是一个core,但整个排查解决的过程还是遇到了不少困难,这里记录了这一次线上core的整个排查过程,希望能够帮助遇到类似问题的同学。
在Native层实现异常处理的关键在于信号处理(Signal Handling)和非局部跳转(Non-Local Jumps)。当程序发生错误(如访问非法内存、除以零等)时,操作系统会向进程发送一个信号。我们可以设置一个信号处理函数(Signal Handler),在收到信号时执行特定的代码。
通过查看php日志/usr/local/php/var/log/php-fpm.log,有如下警告信息:
在一套2节点的19c RAC 环境下,节点2 alert告警 ORA 7445,且频度固定为每分钟报一次;期间有重启实例,但故障依旧:
程序在执行过程中 crash 是非常严重的问题,一般都应该在测试阶段排除掉这些问题,但是总会有漏网之鱼被带到 release 阶段。
在main函数中,return和exit经常混用,两者的一个区别:return会执行statck unwinding,而exit不会。如果触发了信号,exit也同样不会做stack unwinding,除此之外异常如果没有相应的catch,也同样不会有栈展开(stack unwinding)。
网上看到一个很有意思的美团面试题:为什么线程崩溃崩溃不会导致 JVM 崩溃,这个问题我看了不少回答,但发现都没答到根上,所以决定答一答,相信大家看完肯定会有收获,本文分以下几节来探讨
finish:运行程序,知道当前函数完成返回,并打印函数返回时的堆栈地址和返回值及参数值等信息。
现代机器大部分是 64 位的,JVM 也从 9 开始仅提供 64 位的虚拟机。在 JVM 中,一个对象指针,对应进程存储这个对象的虚拟内存的起始位置,也是 64 位大小:
使用 kubectl describe pod 查看异常的 pod 的状态,在容器列表里看 State 字段,其中 ExitCode 即程序退出时的状态码,正常退出时为0。如果不为0,表示异常退出,我们可以分析下原因。
手机user版本还是userdebug或是eng版本:adb shell getprop ro.build.type
在 NDK 开发中,排查问题遇到的最熟悉的关键字非 backtrace 莫属,Linux 系统中进程 crash 后通过 backtrace 输出堆栈信息,开发者就是基于这些堆栈信息来定位代码问题。当然定位 Native 层代码问题最优的方式还是通过 IDE(AS、VS)或者 GDB 进行 debug 断点调试,本文针对的是使用第三方 C/C++ SDK 出现 crash 的场景。
C/C++编写的程序,崩溃后有时不能生成core文件(即使设置了ulimited),所以往往不知道发生了什么事情,生产环境根本不允许研发小朋友去调试,日志有时候看不出问题了。(如果生成了core文件,或通过日志能定位到问题所以,则可略过此文章)。
前言 上一篇给大家介绍了Android Crash中的Java Crash分析,我们可以知道Java Crash一般会弹出提示框告诉我们程序崩溃了,通常使用Crash工具都能够捕获到;本篇博客来谈谈如何针对Native Crash进行分析,它相对与Java层面的Crash有什么特点?如何判断程序Crash是因为Native层导致的?我们怎么去分析它?下面我们一个一个解答这些问题。 Native Crash在Android上的特点 出错时界面不会弹出提示框提醒程序崩溃(Android 5.0以下) 出错时会弹
使用指针时最常见的错误就是没有语法错误的程序运行时直接崩溃,Debug时运行到有问题的一行是,程序崩溃,并在右下角冒出提示SIGSEGV Segmentation fault.(cb环
今天带大家了解下NULL指针是如何形成的? 当然了我们要深入到操作系统中去看看为何访问一个NULL指令会报Segment Fault的错误。
SIGINT的默认处理动作是终止进程,SIGQUIT的默认处理动作是终止进程并且Core Dump,现在我们来验证一下。
我们知道Java崩溃是在Java代码中出现了未捕获异常,导致程序异常退出,常见的异常有:NPE、OOM、ArrayIndexOutOfBoundsException、IllegalStateException、ConcurrentModificationException等等。 还有一类崩溃,也是我们不得不关注,那就是Native层崩溃,这类崩溃不像Java层崩溃那样比较清晰的看出堆栈信息以及具体的崩溃。每当遇到是都要查找分析,写这篇的目的是帮助自己做下记录,也希望能帮到有类似困扰的你,下面我们开始一起学习实践吧。 本文学习实践的demo以张绍文《Android开发高手课》中的例子进行。
在使用DBCA命令创建新的数据库时,DBCA命令无法启动。运行的环境是宿主机64bit+AMD cpu, 而客户机为Linux 32bit + Grid Infrastructure(32) + Oracle database software(32)的情形。原本想着32bit运行的会快一点,没想到Bug 8670579 在执行dbca时再一次被触发,根据Oracel描述,类似的NETCA也会触发这个Bug。 一、故障现象 [oracle@linux1 ~]$ dbca # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x9e0ea498, pid=4242, tid=3086584016 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_17-b02 mixed mode) # Problematic frame: # C [libnnz11.so+0x3c498] # # An error report file with more information is saved as hs_err_pid4242.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted [oracle@linux1 ~]$
我也换个MySQL 8.0.25试一下,一样的碰到:Segmentation fault (core dumped)
有些 BUG 是业务逻辑上的错误导致的,一般不会导致程序崩溃,例如:原本要将两个数相加,但不小心把这两个数相减,而导致结果出错。这时我们可以通过在程序中,使用 printf 这类输出函数来进行打点调试。
当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中引入):
笔者最近在重新整理和编译 Nebula Graph 的第三方依赖,选出两个比较有意思的问题给大家分享一下。
2. 《深入理解java虚拟机》中推荐的CmakeList.txt的github地址,是针对于Windows而言,linux和mac 不太适用. 昨天改了半天还改成功, 但是其中的写法可以学习参考
trap 属于bash的内置命令,所以查看帮助用: help trap, 如果用”man trap“则会跳出bash的帮助文档; trap命令的作用是:对捕获到的SIGNAL ,改变原有的处理action为新的action; A. 支持哪些信号呢? trap -l 可以列出所有支持的signal.
[root@VM-8-35-centos /data/server/fatp_dw_base]# kill -l
领取专属 10元无门槛券
手把手带您无忧上云