- 综合排序
- 最热优先
- 最新优先
- 来自专栏小巫技术博客
Android Crash之Native Crash分析
前言 上一篇给大家介绍了Android Crash中的Java Crash分析，我们可以知道Java Crash一般会弹出提示框告诉我们程序崩溃了，通常使用Crash工具都能够捕获到；本篇博客来谈谈如何针对 Native Crash进行分析，它相对与Java层面的Crash有什么特点？ 如何判断程序Crash是因为Native层导致的？我们怎么去分析它？下面我们一个一个解答这些问题。 Native Crash如何分析？ 既然要分析就必须找到可以分析的东西，我们在分析Java层Crash的时候是通过logcat日志找到对应的出错代码，然而Native层Crash也是可以logcat日志来进行分析的。
4.2K60发布于 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.8K20发布于 2018-07-20 - 来自专栏落影的专栏
iOS crash分析实践
背景 分享一些过去两个月遇到的crash。 根据堆栈信息和日志信息，可以找到用户操作路径，是通过scheme进入分类； 但是直接用真机复现，相同的操作并不会导致crash； 通过分析crash出现的机型和系统特征，发现都是iOS 13以下系统 分析原因后，定位到是先调用scrollToItemAtIndexPath，再调用reloadData导致的异常。 解决方案也很简单，调整为正确的顺序即可。 场景分析： 1、主线程：did注册 =》TTNet初始化 =》发起网络请求 =》 获取公共参数 =》 dispatch_once ； 2、子线程：RPC（网络层）初始化 =》初始化 =》 获取公共参数 通过代码分析，可以知道是BDRpcAsyncOperation持有了某个block；该block持有了其他对象（因为block中访问了该对象）。
2.1K20发布于 2020-06-16 - 来自专栏Linux知识积累
Linux内核Crash分析
在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。 : 20000013 sp : c07e9c28 ip : 00000000 fp : c07e9c64 r10: c6bcc560 r9 : c646a220 r8 : c66a0000 r7 Backtrace: [<c06bed28>] (dev_get_by_flags+0x0/0x140) from [<c071f764>] (arp_process+0xbb4/0xc74) r7: bust_spinlocks(0); do_exit(SIGKILL); } （2） 对于下面的两个信息，在函数show_pte中进行了打印，下面的打印涉及到了页全局目录，页表的知识，暂时先不分析 : 20000013 sp : c07e9c28 ip : 00000000 fp : c07e9c64 r10: c6bcc560 r9 : c646a220 r8 : c66a0000 r7
5.4K20发布于 2019-10-15 - 来自专栏yanlongli_艳龙
Android Native Crash 分析
背景 版本发布后，收集到到异常上报，有部分记录到是native crash。 而上报的native信息，无法直接定位到错误位置。 解决方案： 一，针对可以复现到场景 1,本地debug版本进行复现，crash复现后找到debug版本的so文件（debug版本的so包含调试信息） $ find . jobjectE5ResetEP7_JNIEnvS3_+7) [armeabi-v7a::51e75dab8c5e3fb807f5dc641bdfb96f] #32 pc 006e30b6 /data/ 路径 NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin 二，针对发版后的crash日志收集 针对发版本的apk，需要在编译阶段归档 这样在发生crash时候，才能通过归档的so文件来定位到具体的crash位置。
84920编辑于 2021-12-16 - 来自专栏WeTest质量开放平台团队的专栏
了解和分析iOS Crash
新机型的发布又会让适配相关的同学忙上一阵子啦，并且iOS Crash的问题始终伴随着移动开发者。本文将从三个阶段，由浅入深的介绍如何看懂并分析一篇crash报告，一起身临其境去读懂它吧。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。 表7：一段因为找不到链接库而导致进程被终止的crash report的摘录 Dyld Error Message: Dyld Message: Library not loaded: @rpath/MyCustomFramework.framework
2.7K20发布于 2018-09-15 - 来自专栏linux驱动个人学习
crash工具分析sysdump使用
一、准备环境 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. ffffff80080c1cf0 #7 [ffffffc07b4c7e20] kthread at ffffff80080c7f8c 6）使用dis <addr|symbol>，对给定地址进行反汇编
2.5K20发布于 2020-05-26 - 来自专栏后端码匠
【Android】NDK开发Crash分析
，所有没有权限读取到/data/tombstones日志，本次Crash case使用Logcat日志分析问题；可以看到，日志内容主要由下面几部分组成：（最主要的就是分析崩溃的过程和PID，终止的信号和故障地址和调用堆栈部分 掉的，名称的属性则表示Crash进程的名称以及在文件系统中位置。 调用堆栈信息 调用栈信息是分析程序崩溃的非常重要的一个信息，它主要记录了程序在Crash前的函数调用关系以及当前正在执行函数的信息，上面例中的backtrace的信息如下所示： 2022-11-21 16 这个工具能自动分析tombstone文件，能将崩溃时的调用内存地址和C++代码一行一行对应起来。 ，objdump 则是可以在汇编层对崩溃原因进行分析。
2K40编辑于 2022-12-05 - 来自专栏WeTest质量开放平台团队的专栏
了解和分析iOS Crash
新机型的发布又会让适配相关的同学忙上一阵子啦，并且iOS Crash的问题始终伴随着移动开发者。本文将从三个阶段，由浅入深的介绍如何看懂并分析一篇crash报告，一起身临其境去读懂它吧。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 处理后的结果就是一个符号化过的crash report。 7. 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。
2.2K30发布于 2018-10-29 - 来自专栏用户8156813的专栏
Linux crash分析简明参考
,包括:如何安装kdump,如何设置系统参数来捕获崩溃前的内存;如何使用crash做简单的分析;并且介绍如何使用更加简便的工具PyKdump来做crash文件的分析.通过了解这些知识, 可以帮助Linux 工具分析4.1 安装crash工具为了不影响生产系统的运行,通常我们会将生成的vmcore文件拷贝到用于分析的Linux系统上去分析.分析工具通常采用crash工具.CentOS下可以通过如下命令安装: /Python-3.8.18/make 编译后将生成python库文件.3) 编译crash工具首先下载crash7的压缩包,到如下位置下载: https://github.com/crash-utility 文件分析,命令查看如下:crash . /crash_whitepaper.html4) Red Hat Enterprise Linux 7 Kernel Crash Dump Guidehttps://access.redhat.com/
3.5K00编辑于 2023-12-03 - 来自专栏nimomeng的自我进阶
了解和分析iOS Crash Report
App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 OS 符号表的架构具有独特性——一个64位的iOS设备不会包含armv7的符号表。Xcode将要自动拷贝你连接到的特定版本的Mac的符号表。 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。 表7：一段因为找不到链接库而导致进程被终止的crash report的摘录 Dyld Error Message: Dyld Message: Library not loaded: @rpath/MyCustomFramework.framework
2.7K20发布于 2018-09-13 - 来自专栏开源部署
MySQL实例crash的案例分析
用gdb分析生成的core file，可以看到crash时的堆栈信息如下： 从函数table_esms_by_digest::delete_all_rows可以看出触发crash的是truncate 我们内部有个DML的分析工具，用来统计数据库每分钟增删改查的访问量。 暂停这组集群上DML采集程序后MySQL没有再发生crash。 进一步分析多个core file，发现最终函数的调用都发生在_lf_pinbox_real_free函数上。 结合现场环境，有两处地方值得分析： 1、 内存的不正常值。 (Bug #73979, Bug #19678930, Bug #23224078) 【解决思路】 我们通过分析crash时的core file文件，找到crash时的触发条件，暂停DML采集程序（truncate
1.5K10编辑于 2022-08-17 - 来自专栏Android点滴分享
AudioTrack引发的应用Crash分析
问题背景 crash的堆栈如下： signal: 11 (SIGSEGV), code: 1 (SEGV_MAPERR) fault addr: 0x7434a00010 si_errno:0, si_errnoMsg 0x7f7f7f7f7f7f7f7f r8: 0x0000007434a00000 r9: 0x7fb8960001d68187 r10: 0x0000000000000001 r11: google上搜了下，也有对应的issue，不过没有fix：https://issuetracker.google.com/issues/234934924 其他信息就没有了，那既然别人没分析出来我们要不要分析 当然要，接下来就开始狂飙一样的分析 分析过程 阶段1 堆栈上看是crash到setVolume上了，这个是设置系统硬件音量，我们的业务是绝对不会设置硬件音量，这个就是一个疑点了。 从操作时序上看，每次crash都是先看到析构AudioTrack的信息，然后再看到setVolume的信息，然后就crash了，很自然想到就是操作已经释放的了AudioTrack了，实际上也的确是的。
1.6K30编辑于 2023-02-17 - 来自专栏腾讯数据库技术
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 - 来自专栏落影的专栏
UITabbarController 偶现启动crash问题分析
问题背景 最近新版本发布后，出现了一个偶现的crash并且迅速增加为Top1，这里对该问题做一个分析。 crash堆栈如下： 问题分析 APM分析 首先是查看APM提供的信息，没有系统聚集、没有机型聚集，是版本新增问题都是隐私界面（也就是新用户冷启场景）。 多维分析 由于crash出现在系统的UITabBarController类，无法调试获取更多信息，逆向排查周期太长。这里可以通过Slardar的信息，结合日志和业务场景逐步缩小排查范围。 首先通过crash场景，我们猜测是在用户新用户冷启才会遇到，这里通过回捞日志和crash的pv/uv相比可以确定； 其次通过排查新用户冷启场景的特有逻辑，关注点放在新版本相关的代码和实验改动，发现在底 反向分析 当问题可以稳定复现后，就可以进一步分析逻辑上的缺陷。 首先是vc的复用逻辑分析： App在启动时就要初始化tabbarVC，并且在后续会刷新底tab的数量。
1.1K40编辑于 2022-10-28 - 来自专栏笔记+
利用crash分析内存unused dentry信息
读写文件频繁的环境经常碰到大量dentry占用内存高的情况，本文介绍一种通过crash找到这些dentry 对应的文件的方法。 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问题分析 根据日志信息，初步怀疑是连接打满了，检查最大连接数配置。 " : 7, "active" : 2 } 最大连接数是由 maxIncomingConnections 参数和 ulimit 决定的。 源码分析 在源码 mongo/wiredtiger_kv_engine.cpp[3] 中可以看到 WT_SESSION 硬编码指定为 20000。 为什么相同的操作在主节点可以正常完成，而从节点会发生 Crash？
1K21编辑于 2023-08-18 - 来自专栏雪月清的随笔
使用addr2line分析Native Crash
在Android NDK开发中，Native层的崩溃信息不像Java层的崩溃堆栈那样可以直接看到出现问题的函数名和行数 如上图所示的Native Crash例子，我们需要一些NDK提供的工具将函数地址解析为具体的函数名和行数才能进一步分析问题 linux-android-c++fil(和addr2line同一个目录)是专门用来支持Demangle的 addr2line使用示例 新建一个带C++的Android Studio工程，主动创造一个native crash 解析结果 定位到具体的函数名和行数后就可以进一步排查问题了 Crash堆栈解析脚本 日常工作或者学习中还是使用一个python脚本来解析带crash堆栈的文件比较方便 #! = re.search('#[0-9]+ +pc +([0-9A-Fa-f]+) +/data', line) if crash is not None: addr = crash.groups(1)[0] cmd = CMD_BASE + addr res = os.popen(cmd).read()
2.9K11编辑于 2022-06-09 - 来自专栏皮振伟的专栏
使用systemtap分析qemu发生crash的原因
前言： 在《[linux][pthread]qemu的一次pthread create失败的分析》中分析了pthread失败的原因以及解决方法。 分析： 1，clone fail 作者写了脚本，批量启动大量的qemu进程。在启动很大量的qemu之后，会有部分qemu进程crash。 结合之前的分析过程，作者判断，很可能是系统调用clone发生了失败。是时候使用systemtap了。 centos7的kernel是3.10，在linux3.10中，还不支持pids cgroup。所以libvirt不支持也不是特别惊奇的事情了。那么就要自己想办法修改一下这个配置了。 本文的场景下，当然也可以使用printk来逐步分析～ 这个问题找到root cause，安心多了。
2.3K90发布于 2018-04-09 - 来自专栏深度学习与python
WebView 常见 Crash 分析及解决方案
1 前言 App 出现意外闪退我们称之为 Crash，Crash 率是衡量 App 稳定性的一个重要指标，App 的稳定性不仅影响使用体验，甚至会造成用户流失。 WebView 导致的 Crash 也占据较大比例，有效治理 WebVi ew 导致的 Crash 迫在眉睫。 本文主要讲述 Android WebView 常见 Crash 及解决方案。 问题分析 通过阅读源码发现最终调用到了 AwDataDirLock 中的 lock 方法。 问题分析 Android 8.0 版本的 WebView 在读取 WebView 缓存时出现内存溢出。 解决方案 针对该 Crash，紧急联系相关运营人员中止活动投放，同时将页面替换成文本 + 小图的方式后再次投放，Crash 得以中止。
6.7K20发布于 2021-11-11
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号