一般都要符号化crash日志,但是低内存奔溃却没有堆栈日志
A Low Memory report differs from other crash reports in that there are no backtraces in this type of report. When a low memory crash happens, you must investigate your memory usage patterns and your responses to low memory warnings. This document points to you several memory management references that you might find useful.
内存低的崩溃日志,有一个进程表,列有几种原因。如果没有,可能就不是内存低导致的崩溃,请使用VM Tracker工具来检查。
[per-process-limit]: The process crossed its system-imposed memory limit. Per-process limits on resident memory are established by the system for all applications. Crossing this limit makes the process eligible for termination.
[vm-pageshortage]/[vm-thrashing]/[vm]: The process was killed due to memory pressure.
[vnode-limit]: Too many files are open.
[highwater]: A system daemon crossed its high water mark for memory usage.
[jettisoned]: The process was jettisoned for some other reason.
一般来说,xcode都会自动化符号化,如果没有(比如是从itunes上下载dSYM),可以手动符号化
xcrun dsymutil -symbol-map
xcrun dsymutil -symbol-map ~/Library/Developer/Xcode/Archives/2017-11-23/MyGreatApp\ 11-23-17\,\ 12.00\ PM.xcarchive/BCSymbolMaps ~/Downloads/dSYMs/3B15C133-88AA-35B0-B8BA-84AF76826CE0.dSYM |
xcode符号化需要三种条件
1. APP二进制文件和dSYM
2. 自定义的framework对应的二进制与dSYM
3. 与APP崩溃是的运行OS对应的符号,符号表是与OS相关的。
缺少一个都导致无法完全符号化。
第三方的framework,需要第三方提供作者创建的dSYM文件。
The binaries and
dSYM
files for all custom frameworks that the application links against. For frameworks that were built from source with the application, theirdSYM
files are copied into the archive alongside the application'sdSYM
file. For frameworks that were built by a third-party, you will need to ask the author for thedSYM
file.
没有符号化就要使用atos
Symbolicating Crash Reports With atos
The atos command converts numeric addresses to their symbolic equivalents. If full debug symbol information is available then the output of
atos
will include file name and source line number information. Theatos
command can be used to symbolicate individual addresses in the backtrace of an unsymbolicated, or partially symbolicated, crash report. To symbolicate a part of a crash report usingatos
:
根据Binary Image的UUID找到对应的dSYM
1. 在崩溃日志里面,使用命令行快速找到UUID这一行。
$ grep --after-context=1000 "Binary Images:" <Path to Crash Report> | grep <Binary Name>
2. 32位的UUID转换格式为 8-4-4-4-12 (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
). 全部为大写字母。
3. 使用mfind寻找dSYM文件,其中格式是包括尖括号的
$ mdfind "com_apple_xcode_dsym_uuids == <UUID>"
如果找到对应的dSYM文件,xcode不能解析,这个就是xcode的bug。
如果找不到对应的dSYM文件,检查是否下载对了文件。使用命令行查看Binary Image的UUID
xcrun dwarfdump --uuid <Path to dSYM file>
这个是一个使用例子:
1. 打开xcode
2. 获取APP
ljydeMacBook-Pro:~ admin$ cd /Users/admin/Library/Developer/Xcode/DerivedData/rcpi-hcfcbslblbqkydeyajzrmaoddwou/Bui ld/Products/Debug-iphoneos
ljydeMacBook-Pro:Debug-iphoneos admin$ ls
ProtocolBuffers.framework cwf.framework iwf.framework.dSYM xxx.app
ProtocolBuffers.framework.dSYM iwf.framework libjscocos2d iOS.a xxx.swiftmodule
确保APP的架构版本是跟崩溃的APP的是一样的。
3. 确定版本, 找到你的应用XXX.app文件 通过应用“终端、Terminal” 查看其UUID
在命令行输入“dwarfdump --uuid XXX.app/XXX”
4.定位错误
直接在终端中输入以下命令“atos -o XXX.app/XXX -arch arm64 xxxxxxxx ”
ljydeMacBook-Pro:Debug-iphoneos admin$ atos -o rcpi.app/rcpi -arch arm64 0x0000000100e57fb0 0x0000000100e7e374 0x0000000100e7da38 0x0000000100e7b1d8 tx_ABGRToUVRow_C (in rcpi) + 108 -[TXLiveBeauty addBeautyTarget] (in rcpi) + 876 txrtmp_soundtouch::TDStretch::seekBestOverlapPositionQuick(short const*) (in rcpi) + 276 -[TXLivePushSingleton createPixelBufferAt:width:height:pixelFormatType:] (in rcpi) + 144