我们先来看一种具有代表性的Crash,这里以一次灰度的Top 1 Crash为例子,至于这个Crash的引入原因,开发童鞋为了修改性能bug,将方法放到了线程中执行,我省去中间几百行代码,抽取出代码梗概...如果是两个线程同时并发,一共有4种情况,我用图给您展示两种: 两个线程在并发的情况下,用排列组合的知识,很容易算出发生Crash的概率是50%,那这个概率还是蛮高的,如果更多数量线程并发,Crash...概率更高,那也就不难理解这个Crash是Top 1 Crash了。...在执行语句上暂停 既然是给mTask赋值时出现的问题,一个线程执行后,那我们在这条语句上暂停,像调试一样,等其他线程来覆盖第一个线程的赋值结果,那这个Crash就能完整重现了,可这个方案依旧有不小的难度...模拟线程并发 既然这类线程安全的问题是在多线程并发时出现问题的概率大,避免发生Crash就加同步,避免线程并发访问临界资源,如果要在事发前发现这类问题,那我们就应该反其道而行之,增大线程并发的概率。
前言:昨天碰到了一个 worker_threads crash 的问题,最终经过阅读源码和调试找到了具体原因。不得不说,阅读源码是解决问题的非常有效的方法。 代码例子如下。...问题发生在执行 uv_close 的回调时出现了 crash。...通过调试发现调用 uv_close 时传入的回调函数地址是 A,但是最终执行时地址变成了 B,而 B 是一个非法地址,从而导致了 crash。...uv_run(&loop_, UV_RUN_ONCE); 所以 uv_close 的回调就会被执行,因为这时候回调函数的地址被修改成非法的了,所以导致了 crash。...除了这个问题外,子线程退出前还会检查 loop,如果还有任务没有被关闭也会导致线程 crash。
这类错误一般是由C++层代码错误引起的 绝大部分Crash工具不能够捕获 我们在实际Android开发的时候,可能会引入第三方的一些so库或者自己开发相应的so库供程序使用,然而so库一般是通过c或者...这下子可分析的内容就多起来了,我们逐个来看看: 进程信息:pid表示进程号,tid表示线程号,name表示进程名 错误信号:signal 11表示信号的数字,SIGSEGV表示信号的名字,code 1(...寄存器快照:进程收到错误信号时保存下来的寄存器快照,一共有15个寄存器。 堆栈信息:##00表示栈顶,##01调用#00,以此往下都是嵌套的调用关系,直至到栈顶。...总结 关于Native Crash的特点、产生原因、分析过程已经给大家做了简单的分析,这一块内容是初学者在分析错误的时候最头痛的地方,因为他不知道如何下手,也希望通过这篇文章能帮助到大家对Native...,这里就要隆重推荐大家使用Bugly,可以说是业内领先的崩溃捕获工具,不仅能够帮助我们获取到完整的错误堆栈,还能够将出错的上下文环境参数(比如系统版本、设备信息、内存信息等)详细的展现出来,大家不妨可以尝试下
Native Crash 本篇先探讨Java Crash,Native Crash我们会在下一篇重点讨论。...Java Crash在Android上的特点 这类错误一般是由Java层代码触发的 一般情况下程序出错时会弹出提示框,JVM虚拟机退出 一般的Crash工具都能够捕获,系统也提供了API 举个栗子 ?...这个时候程序就正常运行了,是不是很简单啊,但这种情况是自己在开发中调试运行时可以通过logcat来定位问题,但如果产品上线之后你怎么办,用户都是小白哦,可不会给你提供错误日志,这个就是本篇文章要讲的重点...,如果要让我们自己记录错误日志,怎么做?...(); } /** * 这个是最关键的函数,当程序中有未被捕获的异常,系统将会自动调用#uncaughtException方法 * thread为出现未捕获异常的线程
1、手动捕捉crash 即使有了bugly,也需要知道奔溃是如何捕捉的。 注意:自定义NSSetUncaughtExceptionHandler之后,会导致bugly失效,需要注意!!...//crash奔溃的处理 exception_init(); } void exception_init(void) { // _objc_terminate是一个函数指针...old_terminate = std::set_terminate(&_objc_terminate); } //系统出现crash都会来到这个函数 static void _objc_terminate
[1] Debugging a futex crash: https://rustylife.github.io/2023/08/15/futex-crash.html 很精彩的文章, 水友群一个朋友遇到了一个...No other errors are documented at this time. */ default: futex_fatal_error (); } } 这几个错误是最值得关注的
要实现 Native Crash 的收集,主要有四个重点:知道 Crash 的发生;捕获到 Crash 的位置;获取 Crash 发生位置的函数调用栈;数据能回传到服务器。...所以我们需要设置一个用于紧急处理的新栈,可以使用sigaltstack()在任意线程注册一个可选的栈,保留一下在紧急情况下使用的空间。...只不过需要自己解析函数符号,同时经常会捕获到系统错误,需要手动过滤。...虽然获取到全部想要的信息,但有个麻烦的就是不想要的信息也给你了,所以需要手动过滤掉各种系统错误,最终得到的数据,就可以上报到自己的服务器了。...;如果当前函数发生了无限递归造成堆栈溢出,在统计的时候需要考虑到这种情况而新开堆栈否则本来就满了的堆栈又在当前堆栈处理溢出信号,处理肯定是会失败的;再比方说多进程多线程在 C 上的各种问题,真的是很复杂
用户在使用App的过程中,经常遇到闪退的情况,体验不太好,本文尝试探索引发闪退的原因,以及在遇到crash的情况下,尽可能的保持程序运行,并及时上报错误。...一、crash类型 1.OC层面的crash 1.1 普通类型 NSInvalidArgumentException:非法参数异常,传入非法参数导致异常,nil参数比较常见。...2.Signal层面的crash 除了OC层面的异常捕获之外,很多内存错误、访问错误的地址产生的crash则需要利用unix标准的signal机制,注册SIGABRT, SIGBUS, SIGSEGV等信号发生时的处理函数...二、存在问题 程序闪退,用户体验不好 三、监听crash 1.任凭程序闪退并上报 1.1 NSSetUncaughtExceptionHandler 捕获OC层面的crash 参考文章 (1)AppDelegate...3.Swizzle消息转发机制forwardingTargetForSelector方法,处理所 有原始类originObject的方法,收集错误信息并上报。 4.及时释放zombieObject。
正文 一、运行时错误 1、UICollectionView的调用顺序 从堆栈可以看出是indexPath无效,通常是indexPath的section或者row超过了数据的大小; ?...这段HTML文本在转码的时候会同步对图片资源进行加载,导致线程阻塞,如果阻塞时间过长,还会引发crash。 堆栈如下: ?...堆栈关键信息:dispatch_gate_wait_slow; 注意到上图,crash的是子线程,这时候要习惯性看看主线程在处理什么逻辑: ?...; 子线程发生crash时,要习惯性看看主线程; 三、内存相关 1、dealloc访问weak指针 weak指针经常被应用到在代理、block避免循环引用,避免有一个特性就是对象dealloc的时候...;(不能访问self相关) 总结 1、寻找复现路径的时候,要尽可能还原现场,才能更好复现; 2、使用一个不熟悉的系统API接口,最好花时间阅读下接口说明; 3、子线程发生crash时,要习惯性看看主线程
在工作中经常会遇到一些内核crash的情况,本文就是根据内核出现crash后的打印信息,对其进行了分析,使用的内核版本为:Linux2.6.32。...对每一个进程来说,Linux内核都会把两个不同的数据结构紧凑的存放在一个单独为进程分配的存储空间中:一个是内核态的进程堆栈,另一个是紧挨进程描述符的数据结构thread_info,叫线程描述符。...2.6.32内核中thread_info.h文件中有对内核堆栈的定义: #define THREAD_SIZE 8192 在Linux内核中使用下面的联合结构体表示一个进程的线程描述符和内核栈
crash>log .... [23680089.192513] NMI watchdog: BUG: soft lockup - CPU#11 stuck for 22s!...[filebeat:47277] .... crash> runq .... ......计算截止重启时刻cpu12 多长时间未发生调度: crash> eval 23680089192515189-23680067820641540 hexadecimal: 4f9dce971...> pd 21371873649/1000000000 $1 = 21 crash> eval 21371873649/1000000000 hexadecimal: 15 decimal: 21...octal: 25 binary: 0000000000000000000000000000000000000000000000000000000000010101 crash>
出现问题是,数据库先是被置为只读,然后过了一段时间,MySQL直接Crash掉了,发生Crash时MySQL的error日志中打印了以下内容: ?...根据日志中我们可以看到,线程140363572082432要对记录上一个X锁,但是等待0x7fa949340740线程的RW-Latch的释放。...首先数据库变成了只读,最后数据库Crash了,Crash输出的信息如下: ?...RW-Latch等待超过了600秒还没有返回,认为系统出现了严重问题,于是触发了MySQL服务的Crash。...正是由于这个RW-Latch被长时间占用了,其他的线程一直竞争不到,才导致了这个问题。
背景 版本发布后,收集到到异常上报,有部分记录到是native crash。 而上报的native信息,无法直接定位到错误位置。...解决方案: 一,针对可以复现到场景 1,本地debug版本进行复现,crash复现后找到debug版本的so文件(debug版本的so包含调试信息) $ find ....2,根据堆栈信息,查找错误。...(下面是一个实际发生的错误堆栈) SIGSEGV(SEGV_MAPERR): #00 pc 006e3136 /data/app/***-kELvojZn3xlCIubKv5Vtsw==/lib/arm...这样在发生crash时候,才能通过归档的so文件来定位到具体的crash位置。
昨天在社区上看到有人讨论多线程使用,多线程遇到一些问题以及一些使用技巧记录一下。...用多线程要对线程、线程池、同步机制不断学习,因为多线程是好东西,但坑也是很多。稍有不慎就会导致程序bug、 甚至死锁、线上cpu100%服务不可用。...线程对共享变量 的所有操作都必须在自己的工作内存中进行,不能直接从主线程中获取。因为副本主线程修改子线程为能收到。当 number变量不可见时输出结果为0,当ready不可见时子线程死循环。...再finally中也用了,而finally中时一定会执行的,这时 相当于执行了两次主线程有几率不等待剩余线程向下执行,导致程序偶发bug,这个其实是对finally理解不到位。...这就要求我们要不断研究学习多线程技术,以保证优雅正确将多线程应用到线上服务以及其他各种场景。
如果没有debugger存在,则线程会被终止并生成一个crash report。 底层库(例如libdispatch)会在遇到fatal错误的时候陷入这个困局。...关于错误的相关信息会在crash report的章节或者是设备的的打印信息里找到。...有可能是因为线程在一个配置错误的函数指针的误导下尝试jump到一个无效地址。 在Intel处理器上,ud2操作码会导致一个EXC_BAD_INSTRUCTIONY异常,但是这个通常用来做调试用途。...一种常见原因是在主线程上做网络同步逻辑。不论Thread0上(也就是主线程)想做什么(重要的事),都应该转移到后台线程,或者换一种方式触发,这样它才不会阻塞主线程。...Thread State(线程状态) 这章列出了crash线程的线程状态。这里列出了注册过的值。
一、准备环境 1)获取crash工具。注意区分版本(arm/arm64/x86_64)。 2)获取对应软件版本的符号表文件(如vmlinux),可以将该文件放置 crash工具同一目录下。....* > sysdump.core 4)使用crash工具解析之前生成出来的sysdump.core文件: crash_arm -m phys_base=0x80000000 vmlinux sysdump.core...或:crash vmlinux sysdump.core 二、crash常见命令 分析sysdump的入口界面如下(包括panic描述及PID等): XXXX/demo$ ..../crash_arm64 vmlinux sysdump.core crash_arm64 7.2.3++ Copyright (C) 2002-2017 Red Hat, Inc....crash_arm64> 其中经常用的有:log,ps,sys,mount,sym,rd/wr,bt等。 1)使用sys命令查看系统概况。
去年,网易杭州研究院曾经针对 crash 的防护有提出『大白健康系统--iOS APP 运行时 Crash 自动修复系统』方案,使得 crash 防护这个想法真正被落实,但至今该方案的具体实现并没有被开源...Crash 防护可选的方案 Crash 是什么? 在探讨 Crash 防护的方案之前,我们有必要对计算机领域 Crash 这个概念进行重新认识。...对于 Crash 的概念),维基百科中是这么定义的: In computing, a crash (or system crash) occurs when a computer program, such...不让错误异常产生可以通过多种做法,往项目管理上说提高代码质量,增加 Code Review 等,从编码角度来说,我们可以通过各种保护性代码进行。...因为成熟团队的代码质量相对更高,一些低级错误出现的概率极小。但对于小团队,或者历史比较久的项目而言,这套方案带来的帮助会比较大,毕竟坑总是防不胜防的。
crash> struct mutex ffffffffc05f1000 struct mutex { count = { counter = -2 //初始值为1,每增加一个等锁的进程则减...crash> bt 0xffff960574cdd140 PID: 7272 TASK: ffff960574cdd140 CPU: 2 COMMAND: "reader" #0 [ffff96056078bd48...] kthread at ffffffffb80c1da1 #5 [ffff96056078bf50] ret_from_fork_nospec_begin at ffffffffb8775c24 crash...crash> list 0xffff960539f9fe40 -l mutex_waiter.list -s mutex_waiter ffff960539f9fe40 struct mutex_waiter...0xffff960539f9fe40, prev = 0xffff96057483be40 }, task = 0xffff960574cdd140 } 为什么已经获得锁的进程已经不在wait list里了,crash
7985, tid: 7985, name: gce.ndkpractice >>> cn.com.codingce.ndkpractice <<< 如果pid等于tid,那么就说明这个程序是在主线程中...Crash掉的,名称的属性则表示Crash进程的名称以及在文件系统中位置。...终止信号和故障地址信息 从上面日志中的第11、12行中可以看到程序是因为什么信号导致了Crash以及出现错误的地址,如下所示: 2022-11-21 16:24:58.265 8033-8033/?...A/DEBUG: Cause: null pointer dereference 第10行的信息说明出现进程Crash的原因是因为程序产生了段错误的信号,访问了非法的内存空间,而访问的非法地址是0x0...SIGFPE 算术运算错误,除以零。 SIGILL 非法指令,如执行垃圾或特权指令 SIGSYS 糟糕的系统调用 SIGXCPU 超过CPU时间限制。 SIGXFSZ 文件大小限制。
领取专属 10元无门槛券
手把手带您无忧上云