- 综合排序
- 最热优先
- 最新优先
- 来自专栏小巫技术博客
Android Crash之Native Crash分析
前言 上一篇给大家介绍了Android Crash中的Java Crash分析，我们可以知道Java Crash一般会弹出提示框告诉我们程序崩溃了，通常使用Crash工具都能够捕获到；本篇博客来谈谈如何针对 Native Crash进行分析，它相对与Java层面的Crash有什么特点？ Native Crash如何分析？ 既然要分析就必须找到可以分析的东西，我们在分析Java层Crash的时候是通过logcat日志找到对应的出错代码，然而Native层Crash也是可以logcat日志来进行分析的。 mod=viewthread&tid=27&extra=page%3D4 我们在栈顶就已经看到我们出错的地方了： #00 pc 00000730 /data/app-lib/com.devilwwj.jnidemo
4K60发布于 2018-07-20 - 来自专栏小巫技术博客
Android Crash之Java Crash分析
本系列博文主要是想跟大家分享一下在Android平台中如何进行Crash分析并解决问题并告诉大家如何通过bugly进行崩溃捕获快速定位问题。 什么是Crash？ 这里我们进行一些概念上的普及： Crash就是由于代码异常而导致App非正常退出现象，也就是我们常说的『崩溃』 Android中有哪些类型Crash 通常情况下会有以下两种类型Crash： Java Crash Native Crash 本篇先探讨Java Crash，Native Crash我们会在下一篇重点讨论。 当然上面只适用于Java Crash捕获，如果想更专业捕获到异常并更高效分析程序问题，可以尝试使用专业的第三方SDK来实现，这里推荐『腾讯Bugly』，可以参考一下笔者前面发表的文章『快速集成Bugly 总结 关于Java Crash的分析已经介绍完了，相对还是比较简单，通过简单的方式就能够捕获到异常，但别忘了，Android最头痛的不是这种异常，而是Native层的异常，有时候就算能让你拿到堆栈信息你也不一定会解决问题
1.7K20发布于 2018-07-20 - 来自专栏落影的专栏
iOS crash分析实践
背景 分享一些过去两个月遇到的crash。 根据堆栈信息和日志信息，可以找到用户操作路径，是通过scheme进入分类； 但是直接用真机复现，相同的操作并不会导致crash； 通过分析crash出现的机型和系统特征，发现都是iOS 13以下系统 分析原因后，定位到是先调用scrollToItemAtIndexPath，再调用reloadData导致的异常。 解决方案也很简单，调整为正确的顺序即可。 通过代码分析，可以知道是BDRpcAsyncOperation持有了某个block；该block持有了其他对象（因为block中访问了该对象）。 dispatch_async的方式，放到主线程去执行；（不能访问self相关） 总结 1、寻找复现路径的时候，要尽可能还原现场，才能更好复现； 2、使用一个不熟悉的系统API接口，最好花时间阅读下接口说明； 3、
2K20发布于 2020-06-16 - 来自专栏Linux知识积累
Linux内核Crash分析
在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。 我们在C语言书上看到过关于union的解释，在在C Programming Language 一书中对于联合体是这么描述的： 1) 联合体是一个结构； 2) 它的所有成员相对于基地址的偏移量都为0； 3) l3_rule_add Modules linked in: splic mmp(P) CPU: 0 Tainted: P (2.6.32.11 #42) PC is at c025c3f4 9f80: 60000013 ffffffff c07e9fb4 c07e9f98 c025c578 c025c3cc 00000000 c0981204 9fa0: c0025ca0 bust_spinlocks(0); do_exit(SIGKILL); } （2） 对于下面的两个信息，在函数show_pte中进行了打印，下面的打印涉及到了页全局目录，页表的知识，暂时先不分析
5.2K20发布于 2019-10-15 - 来自专栏yanlongli_艳龙
Android Native Crash 分析
背景 版本发布后，收集到到异常上报，有部分记录到是native crash。 而上报的native信息，无法直接定位到错误位置。 解决方案： 一，针对可以复现到场景 1,本地debug版本进行复现，crash复现后找到debug版本的so文件（debug版本的so包含调试信息） $ find . EE+3) [armeabi-v7a::51e75dab8c5e3fb807f5dc641bdfb96f] #35 pc 006e30aa /data/app/***-kELvojZn3xlCIubKv5Vtsw arm-linux-androideabi-addr2line 路径 NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin 二，针对发版后的crash 这样在发生crash时候，才能通过归档的so文件来定位到具体的crash位置。
77620编辑于 2021-12-16 - 来自专栏linux驱动个人学习
crash工具分析sysdump使用
一、准备环境 1）获取crash工具。注意区分版本（arm/arm64/x86_64）。 2）获取对应软件版本的符号表文件（如vmlinux），可以将该文件放置 crash工具同一目录下。 3）获取sysdump文件，并把所有sysdump文件追加到一个文件sysdump.core中： cat sysdump.core.* > sysdump.core 4）使用crash工具解析之前生成出来的 二、crash常见命令 分析sysdump的入口界面如下（包括panic描述及PID等）： XXXX/demo$ . /crash_arm64 vmlinux sysdump.core crash_arm64 7.2.3++ Copyright (C) 2002-2017 Red Hat, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software:
2.4K20发布于 2020-05-26 - 来自专栏WeTest质量开放平台团队的专栏
了解和分析iOS Crash
新机型的发布又会让适配相关的同学忙上一阵子啦，并且iOS Crash的问题始终伴随着移动开发者。本文将从三个阶段，由浅入深的介绍如何看懂并分析一篇crash报告，一起身临其境去读懂它吧。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 [3.png] [ 相同堆栈信息下的不同程度的符号化 ] 用Xcode符号化iOS的Crash report 一般来说，Xcode会自动尝试符号化它所有的Crash report。 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。
2.4K20发布于 2018-09-15 - 来自专栏python3
A Crash Course in 3D
How much 3D math do you really need to know to survive(为了生存，你需要多少3D数学呢？)? That’s what the next two sections are going to be about—3D math survival skills(接下来的2个小段就是关于如何生存下来的3D can represent a four-component floating-point vector (x, y, z, w), and so on(例如，vmath::vec3就可以表达3个浮点数组成的向量 vmath::vec3 and vmath::vec4 are defined simply as follows(vmath::vec3和vmath::vec4的定义如下) typedef Tvec3 vmath::vVerts[] = { vmath::vec3(-0.5f, 0.0f, 0.0f), vmath::vec3(0.5f, 0.0f, 0.0f), vmath::vec3
67320发布于 2020-01-10 - 来自专栏后端码匠
【Android】NDK开发Crash分析
，所有没有权限读取到/data/tombstones日志，本次Crash case使用Logcat日志分析问题；可以看到，日志内容主要由下面几部分组成：（最主要的就是分析崩溃的过程和PID，终止的信号和故障地址和调用堆栈部分 掉的，名称的属性则表示Crash进程的名称以及在文件系统中位置。 调用堆栈信息 调用栈信息是分析程序崩溃的非常重要的一个信息，它主要记录了程序在Crash前的函数调用关系以及当前正在执行函数的信息，上面例中的backtrace的信息如下所示： 2022-11-21 16 这个工具能自动分析tombstone文件，能将崩溃时的调用内存地址和C++代码一行一行对应起来。 ，objdump 则是可以在汇编层对崩溃原因进行分析。
1.8K40编辑于 2022-12-05 - 来自专栏WeTest质量开放平台团队的专栏
了解和分析iOS Crash
新机型的发布又会让适配相关的同学忙上一阵子啦，并且iOS Crash的问题始终伴随着移动开发者。本文将从三个阶段，由浅入深的介绍如何看懂并分析一篇crash报告，一起身临其境去读懂它吧。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 注意：想要解析来自于测试、app review或者客户的crash report，你需要保留分发出去的那些构建过的archive文件。 3. 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。
2K30发布于 2018-10-29 - 来自专栏用户8156813的专栏
Linux crash分析简明参考
,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux vmcore所对应的OS版本相同的调试信息文件,也即debuginfo,并安装crash工具来分析vmcore.为了简化分析,我们这里引入了PyKdump插件.整体步骤如下图所示:3 配置kdump工具 工具分析4.1 安装crash工具为了不影响生产系统的运行,通常我们会将生成的vmcore文件拷贝到用于分析的Linux系统上去分析.分析工具通常采用crash工具.CentOS下可以通过如下命令安装: /Python-3.8.18/make 编译后将生成python库文件.3) 编译crash工具首先下载crash7的压缩包,到如下位置下载: https://github.com/crash-utility 文件分析,命令查看如下:crash .
3.3K00编辑于 2023-12-03 - 来自专栏nimomeng的自我进阶
了解和分析iOS Crash Report
App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 图3 相同堆栈信息下的不同程度的符号化 用Xcode符号化iOS的Crash report 一般来说，Xcode会自动尝试符号化它所有的Crash report。 列表3 使用mdfind命令来通过给定UUID查找dSYM文件。 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。
2.4K20发布于 2018-09-13 - 来自专栏开源部署
MySQL实例crash的案例分析
[mysqld_safe] core-file-size=unlimited 2、修改系统参数，配置suid_dumpable echo 1 >/proc/sys/fs/suid_dumpable 3、 重启mysql服务，配置生效 【问题分析】 开启core dump后，服务器再次crash时生成了core file。 用gdb分析生成的core file，可以看到crash时的堆栈信息如下： 从函数table_esms_by_digest::delete_all_rows可以看出触发crash的是truncate 暂停这组集群上DML采集程序后MySQL没有再发生crash。 进一步分析多个core file，发现最终函数的调用都发生在_lf_pinbox_real_free函数上。 (Bug #73979, Bug #19678930, Bug #23224078) 【解决思路】 我们通过分析crash时的core file文件，找到crash时的触发条件，暂停DML采集程序（truncate
1.4K10编辑于 2022-08-17 - 来自专栏Android点滴分享
AudioTrack引发的应用Crash分析
问题背景 crash的堆栈如下： signal: 11 (SIGSEGV), code: 1 (SEGV_MAPERR) fault addr: 0x7434a00010 si_errno:0, si_errnoMsg pid:0, sending uid:0 r0: 0x0000000000000000 r1: 0x00000076fd4782e8 r2: 0x0000000000000050 r3: google上搜了下，也有对应的issue，不过没有fix：https://issuetracker.google.com/issues/234934924 其他信息就没有了，那既然别人没分析出来我们要不要分析 当然要，接下来就开始狂飙一样的分析 分析过程 阶段1 堆栈上看是crash到setVolume上了，这个是设置系统硬件音量，我们的业务是绝对不会设置硬件音量，这个就是一个疑点了。 从操作时序上看，每次crash都是先看到析构AudioTrack的信息，然后再看到setVolume的信息，然后就crash了，很自然想到就是操作已经释放的了AudioTrack了，实际上也的确是的。
1.5K30编辑于 2023-02-17 - 来自专栏落影的专栏
UITabbarController 偶现启动crash问题分析
问题背景 最近新版本发布后，出现了一个偶现的crash并且迅速增加为Top1，这里对该问题做一个分析。 crash堆栈如下： 问题分析 APM分析 首先是查看APM提供的信息，没有系统聚集、没有机型聚集，是版本新增问题都是隐私界面（也就是新用户冷启场景）。 多维分析 由于crash出现在系统的UITabBarController类，无法调试获取更多信息，逆向排查周期太长。这里可以通过Slardar的信息，结合日志和业务场景逐步缩小排查范围。 反向分析 当问题可以稳定复现后，就可以进一步分析逻辑上的缺陷。 首先是vc的复用逻辑分析： App在启动时就要初始化tabbarVC，并且在后续会刷新底tab的数量。 在设置新的tabbarVC的viewController属性时，将复用vc从旧的tabbarVC的viewController移除；（这是UIKit的默认做法，但是需要修改tabbarVC的组件） 方案3：
1.1K40编辑于 2022-10-28 - 来自专栏腾讯数据库技术
slave crash unsafe常见问题分析
master_info_repository relay_log_info_repository sync这些信息的频率参数 sync_master_info sync_relay_log_info 本文主要分析由于 「第二部分 分析」 slave crash后建立主从报错的原因可能是因为slave crash前后实例相关状态信息不一致造成的，而这些可能出现的不一致主要是MySQL中的非事务操作（主要表现为非原子性） 下面来分析它们的不一致行为以及这些不一致行为可能造成的问题。 master.info`文件，但不会sync| | /-- my_sync # 每执行sync_master_info次Rpl_info_file::do_flush_info时，会执行这一步 下面分析在 下面是分析过程中两个slave crash后不一致案例： 案例ID 主从同步多少个event后导致crash crash时slave上master info中relay log位点信息 crash时slave
1K10发布于 2021-04-08 - 来自专栏笔记+
利用crash分析内存unused dentry信息
读写文件频繁的环境经常碰到大量dentry占用内存高的情况，本文介绍一种通过crash找到这些dentry 对应的文件的方法。 super_block.s_dentry_lru -h " :%s/^/list super_block.s_dentry_lru -h / 注：ffff882fb855a000为super_block地址 3, grep -v list` ;do printf 0x%x $((0x$i - 0x88));echo "";done > list_dentry.txt 5，修改list_dentry.txt文件得到crash
1.8K20发布于 2020-05-31 - 来自专栏爱可生开源社区
故障分析 | MongoDB 索引操作导致 Crash
---- 1故障现象 近日，朋友遇到一个 MongoDB 实例 Crash 的问题，找到我帮忙一起分析原因，事情经过以及分析过程如下，可供学习。 2问题分析 根据日志信息，初步怀疑是连接打满了，检查最大连接数配置。 源码分析 在源码 mongo/wiredtiger_kv_engine.cpp[3] 中可以看到 WT_SESSION 硬编码指定为 20000。 为什么相同的操作在主节点可以正常完成，而从节点会发生 Crash？ 3问题复现 下面的案例在测试环境复现 WT_SESSION 超过限制的情况，dropIndex 导致从节点锁阻塞的问题有兴趣可自己测试复现，这里就不做演示了。
87821编辑于 2023-08-18 - 来自专栏皮振伟的专栏
使用systemtap分析qemu发生crash的原因
前言： 在《[linux][pthread]qemu的一次pthread create失败的分析》中分析了pthread失败的原因以及解决方法。 分析： 1，clone fail 作者写了脚本，批量启动大量的qemu进程。在启动很大量的qemu之后，会有部分qemu进程crash。 结合之前的分析过程，作者判断，很可能是系统调用clone发生了失败。是时候使用systemtap了。 3，cgroup check fail ? 可见，是cgroup检查出错了。 4，cgroup pids 在linux-4.4/kernel/cgroup.c中，继续分析： ? 本文的场景下，当然也可以使用printk来逐步分析～ 这个问题找到root cause，安心多了。
2.2K90发布于 2018-04-09 - 来自专栏雪月清的随笔
使用addr2line分析Native Crash
在Android NDK开发中，Native层的崩溃信息不像Java层的崩溃堆栈那样可以直接看到出现问题的函数名和行数 如上图所示的Native Crash例子，我们需要一些NDK提供的工具将函数地址解析为具体的函数名和行数才能进一步分析问题 将C++源代码转换为C++ ABI标识符的过程称为mangle，相反的过程称为demangle 以Linux下的g++为例，每个方法都以_Z开头，比如_Z3foov就是函数foo()，v表示参数类型为void 从foo()转换为_Z3foov的过程被称为mangle，_Z3foov转换为foo()的过程被称为demangle。 解析结果 定位到具体的函数名和行数后就可以进一步排查问题了 Crash堆栈解析脚本 日常工作或者学习中还是使用一个python脚本来解析带crash堆栈的文件比较方便 #! bin/python import sys import re import os ADDR2LINE_PATH ='your tool abs path' if len(sys.argv) >= 3:
2.8K11编辑于 2022-06-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号