- 综合排序
- 最热优先
- 最新优先
- 来自专栏小巫技术博客
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日志来进行分析的。
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.6K20发布于 2018-07-20 - 来自专栏落影的专栏
iOS crash分析实践
背景 分享一些过去两个月遇到的crash。 根据堆栈信息和日志信息，可以找到用户操作路径，是通过scheme进入分类； 但是直接用真机复现，相同的操作并不会导致crash； 通过分析crash出现的机型和系统特征，发现都是iOS 13以下系统 分析原因后，定位到是先调用scrollToItemAtIndexPath，再调用reloadData导致的异常。 解决方案也很简单，调整为正确的顺序即可。 场景分析： 1、主线程：did注册 =》TTNet初始化 =》发起网络请求 =》 获取公共参数 =》 dispatch_once ； 2、子线程：RPC（网络层）初始化 =》初始化 =》 获取公共参数 通过代码分析，可以知道是BDRpcAsyncOperation持有了某个block；该block持有了其他对象（因为block中访问了该对象）。
2K20发布于 2020-06-16 - 来自专栏Linux知识积累
Linux内核Crash分析
在工作中经常会遇到一些内核crash的情况，本文就是根据内核出现crash后的打印信息，对其进行了分析，使用的内核版本为：Linux2.6.32。 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 . arm-linux-androideabi-addr2line 路径 NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin 二，针对发版后的crash 这样在发生crash时候，才能通过归档的so文件来定位到具体的crash位置。
76720编辑于 2021-12-16 - 来自专栏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. crash_arm64> 其中经常用的有：log，ps，sys，mount，sym，rd/wr，bt等。 1）使用sys命令查看系统概况。
2.4K20发布于 2020-05-26 - 来自专栏WeTest质量开放平台团队的专栏
了解和分析iOS Crash
新机型的发布又会让适配相关的同学忙上一阵子啦，并且iOS Crash的问题始终伴随着移动开发者。本文将从三个阶段，由浅入深的介绍如何看懂并分析一篇crash报告，一起身临其境去读懂它吧。 当app发生crash时会产生crash report，这对我们定位crash的原因非常有帮助。该篇重点介绍了如何符号化、看懂并解析一篇crash Report。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。
2.4K20发布于 2018-09-15 - 来自专栏后端码匠
【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时会产生crash report，这对我们定位crash的原因非常有帮助。该篇重点介绍了如何符号化、看懂并解析一篇crash Report。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 分析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下可以通过如下命令安装: ,并且要对照Linux源代码进行分析,其门槛比较高,新手短时间内很难掌握.还好有PyKdump工具,该工具以python语言编写,集合了常用的vmcore文件分析功能,可以作为crash插件的方式运行, 文件分析,命令查看如下:crash .
3.2K00编辑于 2023-12-03 - 来自专栏nimomeng的自我进阶
了解和分析iOS Crash Report
当app发生crash时会产生crash report，这对我们定位crash的原因非常有帮助。这篇文档重点介绍了如何符号化、看懂并解析一篇crash Report。 App发布指南里的分析Crash Reports讨论了如何查看那些crash report，这些report既包含通过TestFlight下载的测试用户处获得，又包含通过App Store下载的正式用户处获得 App Store在符号化crash report后会把内部所有的crash reports做汇总并分组，这种聚合（相似crash report）的方法叫做crash聚类。 分析Crash report 这段将会讨论一篇标准crash report的各章节的含义。 Header 每一篇crash report都有一个header。 你应该运行Profile，仔细分析一下extension的各部分消耗时间，把耗时较多的逻辑放到background或者推迟（推迟到extension加载完毕）。
2.3K20发布于 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.4K10编辑于 2022-08-17 - 来自专栏Android点滴分享
AudioTrack引发的应用Crash分析
问题背景 crash的堆栈如下： signal: 11 (SIGSEGV), code: 1 (SEGV_MAPERR) fault addr: 0x7434a00010 si_errno:0, si_errnoMsg google上搜了下，也有对应的issue，不过没有fix：https://issuetracker.google.com/issues/234934924 其他信息就没有了，那既然别人没分析出来我们要不要分析 当然要，接下来就开始狂飙一样的分析 分析过程 阶段1 堆栈上看是crash到setVolume上了，这个是设置系统硬件音量，我们的业务是绝对不会设置硬件音量，这个就是一个疑点了。 从操作时序上看，每次crash都是先看到析构AudioTrack的信息，然后再看到setVolume的信息，然后就crash了，很自然想到就是操作已经释放的了AudioTrack了，实际上也的确是的。 阶段2 接下来只能从源码角度分析了，首先找到PlayerBase的setVolume： binder::Status PlayerBase::setVolume(float vol) { ALOGD
1.5K30编辑于 2023-02-17 - 来自专栏落影的专栏
UITabbarController 偶现启动crash问题分析
问题背景 最近新版本发布后，出现了一个偶现的crash并且迅速增加为Top1，这里对该问题做一个分析。 crash堆栈如下： 问题分析 APM分析 首先是查看APM提供的信息，没有系统聚集、没有机型聚集，是版本新增问题都是隐私界面（也就是新用户冷启场景）。 多维分析 由于crash出现在系统的UITabBarController类，无法调试获取更多信息，逆向排查周期太长。这里可以通过Slardar的信息，结合日志和业务场景逐步缩小排查范围。 首先通过crash场景，我们猜测是在用户新用户冷启才会遇到，这里通过回捞日志和crash的pv/uv相比可以确定； 其次通过排查新用户冷启场景的特有逻辑，关注点放在新版本相关的代码和实验改动，发现在底 反向分析 当问题可以稳定复现后，就可以进一步分析逻辑上的缺陷。 首先是vc的复用逻辑分析： App在启动时就要初始化tabbarVC，并且在后续会刷新底tab的数量。
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
99210发布于 2021-04-08 - 来自专栏爱可生开源社区
故障分析 | MongoDB 索引操作导致 Crash
---- 1故障现象 近日，朋友遇到一个 MongoDB 实例 Crash 的问题，找到我帮忙一起分析原因，事情经过以及分析过程如下，可供学习。 2问题分析 根据日志信息，初步怀疑是连接打满了，检查最大连接数配置。 net: maxIncomingConnections: 30000 在测试环境模拟连接数打满的情况，发现在连接数满了的情况下实例只会拒绝新的连接，而非直接 Crash。 源码分析 在源码 mongo/wiredtiger_kv_engine.cpp[3] 中可以看到 WT_SESSION 硬编码指定为 20000。 为什么相同的操作在主节点可以正常完成，而从节点会发生 Crash？
83021编辑于 2023-08-18 - 来自专栏笔记+
利用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 - 来自专栏皮振伟的专栏
使用systemtap分析qemu发生crash的原因
前言： 在《[linux][pthread]qemu的一次pthread create失败的分析》中分析了pthread失败的原因以及解决方法。 分析： 1，clone fail 作者写了脚本，批量启动大量的qemu进程。在启动很大量的qemu之后，会有部分qemu进程crash。 结合之前的分析过程，作者判断，很可能是系统调用clone发生了失败。是时候使用systemtap了。 2，stap error 继续分析linux-4.4/kernel/fork.c， clone的核心实现部分在copy process中，发现在下面的逻辑中都可能返回： ? 本文的场景下，当然也可以使用printk来逐步分析～ 这个问题找到root cause，安心多了。
2.2K90发布于 2018-04-09 - 来自专栏雪月清的随笔
使用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.7K11编辑于 2022-06-09 - 来自专栏虚拟化笔记
kvm环境下分析虚拟机crash
云上环境运行虚拟机有qemu crash，qemu进程本身代码异常或者被host OOM了，gdb看qemu core或者看host上log，但更多的是windows guest蓝屏和linux guest panic，guest crash后host上qemu进程正常，大概率是guest本身的问题或者guest和host配合的问题，都是开发人员先分析，确定是用户自己的应用导致的才能甩锅，要不然都是云的问题 不管是windows还是linux crash时保留好内存和CPU状态就可以用工具分析。 root@rg1-ostack37 /home/huiwei]# file instance-00000b2e.dmp instance-00000b2e.dmp: MS Windows 64bit crash 参考文献 解压vmlinuz和解压initrd（initramfs) - 笑遍世界 Extracting Windows VM crash dumps
2.4K30发布于 2021-02-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号