crash report

http://bbs.9ria.com/thread-200126-1-1.html

http://go3k.org/?p=258

通过崩溃捕获和收集，可以收集到已发布应用（游戏）的异常，以便开发人员发现和修改bug，对于提高软件质量有着极大的帮助。本文介绍了iOS和android平台下崩溃捕获和收集的原理及步骤，不过如果是个人开发应用或者没有特殊限制的话，就不用往下看了，直接把友盟sdk（一个统计分析sdk）加入到工程中就万事大吉了，其中的错误日志功能完全能够满足需求，而且不需要额外准备接收服务器。但是如果你对其原理更感兴趣，或者像我一样必须要兼容公司现有的bug收集系统，那么下面的东西就值得一看了。

要实现崩溃捕获和收集的困难主要有这么几个：
1、如何捕获崩溃（比如c++常见的野指针错误或是内存读写越界，当发生这些情况时程序不是异常退出了吗，我们如何捕获它呢）
2、如何获取堆栈信息（告诉我们崩溃是哪个函数，甚至是第几行发生的，这样我们才可能重现并修改问题）
3、将错误日志上传到指定服务器（这个最好办）

我们先进行一个简单的综述。会引发崩溃的代码本质上就两类，一个是c++语言层面的错误，比如野指针，除零，内存访问异常等等；另一类是未捕获异常（Uncaught Exception），iOS下面最常见的就是objective-c的NSException（通过@throw抛出，比如，NSArray访问元素越界），android下面就是java抛出的异常了。这些异常如果没有在最上层try住，那么程序就崩溃了。无论是iOS还是android系统，其底层都是unix或者是类unix系统，对于第一类语言层面的错误，可以通过信号机制来捕获（signal或者是sigaction，不要跟qt的信号插槽弄混了），即任何系统错误都会抛出一个错误信号，我们可以通过设定一个回调函数，然后在回调函数里面打印并发送错误日志。

一、iOS平台的崩溃捕获和收集
1、设置开启崩溃捕获

[cpp]view plaincopyprint?

static int s_fatal_signals[] = {
SIGABRT,
SIGBUS,
SIGFPE,
SIGILL,
SIGSEGV,
SIGTRAP,
SIGTERM,
SIGKILL,
};
static const char* s_fatal_signal_names[] = {
"SIGABRT",
"SIGBUS",
"SIGFPE",
"SIGILL",
"SIGSEGV",
"SIGTRAP",
"SIGTERM",
"SIGKILL",
};
static int s_fatal_signal_num = sizeof(s_fatal_signals) / sizeof(s_fatal_signals[0]);
void InitCrashReport()
{
// 1 linux错误信号捕获
for (int i = 0; i < s_fatal_signal_num; ++i) {
signal(s_fatal_signals[i], SignalHandler);
}
// 2 objective-c未捕获异常的捕获
NSSetUncaughtExceptionHandler(&HandleException);
}

复制代码

在游戏的最开始调用InitCrashReport()函数来开启崩溃捕获。注释1处对应上文所说的第一类崩溃，注释2处对应objective-c（或者说是UIKit Framework）抛出但是没有被处理的异常。
2、打印堆栈信息

[cpp] view plain copy print ?

+ (NSArray *)backtrace

{

void* callstack[128];

int frames = backtrace(callstack, 128);

char **strs = backtrace_symbols(callstack, frames);

int i;

NSMutableArray *backtrace = [NSMutableArray arrayWithCapacity:frames];

for (i = kSkipAddressCount;

i < __min(kSkipAddressCount + kReportAddressCount, frames);

++i) {

[backtrace addObject:[NSString stringWithUTF8String:strs[i]]];

}

free(strs);

return backtrace;

}

复制代码

幸好，苹果的iOS系统支持backtrace，通过这个函数可以直接打印出程序崩溃的调用堆栈。优点是，什么符号函数表都不需要，也不需要保存发布出去的对应版本，直接查看崩溃堆栈。缺点是，不能打印出具体哪一行崩溃，很多问题知道了是哪个函数崩的，但是还是查不出是因为什么崩的

3、日志上传，这个需要看实际需求，比如我们公司就是把崩溃信息http post到一个php服务器。这里就不多做声明了。
4、技巧---崩溃后程序保持运行状态而不退出

[cpp] view plain copy print ?

CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop);
while (!dismissed)
{
for (NSString *mode in (__bridge NSArray *)allModes)
{
CFRunLoopRunInMode((__bridge CFStringRef)mode, 0.001, false);
}
}
CFRelease(allModes);

复制代码

在崩溃处理函数上传完日志信息后，调用上述代码，可以重新构建程序主循环。这样，程序即便崩溃了，依然可以正常运行（当然，这个时候是处于不稳定状态，但是由于手持游戏和应用大多是短期操作，不会有挂机这种说法，所以稳定与否就无关紧要了）。玩家甚至感受不到崩溃。

这里要在说明一个感念，那就是“可重入（reentrant）”。简单来说，当我们的崩溃回调函数是可重入的时候，那么再次发生崩溃的时候，依然可以正常运行这个新的函数；但是如果是不可重入的，则无法运行（这个时候就彻底死了）。要实现上面描述的效果，并且还要保证回调函数是可重入的几乎不可能。所以，我测试的结果是，objective-c的异常触发多少次都可以正常运行。但是如果多次触发错误信号，那么程序就会卡死。所以要慎重决定是否要应用这个技巧。

二、android崩溃捕获和收集

1、android开启崩溃捕获
首先是java代码的崩溃捕获，这个可以仿照最下面的完整代码写一个UncaughtExceptionHandler，然后在所有的Activity的onCreate函数最开始调用

Thread.setDefaultUncaughtExceptionHandler(new UncaughtExceptionHandler(this));
这样，当发生崩溃的时候，就会自动调用UncaughtExceptionHandler的public void uncaughtException(Thread thread, Throwable exception)函数，其中的exception包含堆栈信息，我们可以在这个函数里面打印我们需要的信息，并且上传错误日志
然后是重中之重，jni的c++代码如何进行崩溃捕获。

[cpp] view plain copy print ?

void InitCrashReport()
{
CCLOG("InitCrashReport");
// Try
to catch crashes...
struct sigaction handler;
memset(&handler, 0,
sizeof(struct sigaction));
handler.sa_sigaction =
android_sigaction;
handler.sa_flags
= SA_RESETHAND;
#define CATCHSIG(X) sigaction(X, &handler,
&old_sa[X])
CATCHSIG(SIGILL);
CATCHSIG(SIGABRT);
CATCHSIG(SIGBUS);
CATCHSIG(SIGFPE);
CATCHSIG(SIGSEGV);
CATCHSIG(SIGSTKFLT);
CATCHSIG(SIGPIPE);
}

复制代码

通过singal的设置，当崩溃发生的时候就会调用android_sigaction函数。这同样是linux的信号机制。此处设置信号回调函数的代码跟iOS有点不同，这个只是同一个功能的两种不同写法，没有本质区别。有兴趣的可以google下两者的区别。

2、打印堆栈
java语法可以直接通过exception获取到堆栈信息，但是jni代码不支持backtrace，那么我们如何获取堆栈信息呢？这里有个我想尝试的新方法，就是使用google breakpad，貌似它现在完整的跨平台了（支持windows, mac, linux, iOS和android等），它自己实现了一套minidump，在android上面限制会小很多。但是这个库有些大，估计要加到我们的工程中不是一件非常容易的事，所以我们还是使用了简洁的“传统”方案。思路是，当发生崩溃的时候，在回调函数里面调用一个我们在Activity写好的静态函数。在这个函数里面通过执行命令获取logcat的输出信息（输出信息里面包含了jni的崩溃地址），然后上传这个崩溃信息。当我们获取到崩溃信息后，可以通过arm-linux-androideabi-addr2line（具体可能不是这个名字，在android ndk里面搜索*addr2line，找到实际的程序）解析崩溃信息。

jni的崩溃回调函数如下：

[cpp] view plain copy print ?

void android_sigaction(int
signal, siginfo_t *info, void
*reserved)
{
if (!g_env) {
return;
}
jclass classID =
g_env->FindClass(CLASS_NAME);
if (!classID) {
return;
}
jmethodID
methodID = g_env->GetStaticMethodID(classID, "onNativeCrashed", "()V");
if (!methodID) {
return;
}
g_env->CallStaticVoidMethod(classID, methodID);
old_sa[signal].sa_handler(signal);
}

复制代码

可以看到，我们仅仅是通过jni调用了java的一个函数，然后所有的处理都是在java层面完成。

java对应的函数实现如下：

[java] view plain copy print ?

publicstaticvoid
onNativeCrashed() {
//
http://stackoverflow.com/questions/1083154/how-can-i-catch-sigsegv-segmentation-fault-and-get-a-stack-trace-under-jni-on-a
Log.e("handller", "handle");
new RuntimeException("crashed here (native trace should follow after the Java
trace)").printStackTrace();
s_instance.startActivity(new
Intent(s_instance, CrashHandler.class));
}

复制代码

我们开启了一个新的activity，因为当jni发生崩溃的时候，原始的activity可能已经结束掉了。这个新的activity实现如下：

[java] view plain copy print ?

public class CrashHandler extends Activity
{
public static final String TAG = "CrashHandler";
protected void onCreate(Bundle state)
{
super.onCreate(state);
setTitle(R.string.crash_title);
setContentView(R.layout.crashhandler);
TextView v = (TextView)findViewById(R.id.crashText);
v.setText(MessageFormat.format(getString(R.string.crashed), getString(R.string.app_name)));
final Button b = (Button)findViewById(R.id.report),
c = (Button)findViewById(R.id.close);
b.setOnClickListener(new View.OnClickListener(){
public void onClick(View v){
final ProgressDialog progress = new ProgressDialog(CrashHandler.this);
progress.setMessage(getString(R.string.getting_log));
progress.setIndeterminate(true);
progress.setCancelable(false);
progress.show();
final AsyncTask task = new LogTask(CrashHandler.this, progress).execute();
b.postDelayed(new Runnable(){
public void run(){
if (task.getStatus() == AsyncTask.Status.FINISHED)
return;
// It's probably one of these devices where some fool broke logcat.
progress.dismiss();
task.cancel(true);
new AlertDialog.Builder(CrashHandler.this)
.setMessage(MessageFormat.format(getString(R.string.get_log_failed), getString(R.string.author_email)))
.setCancelable(true)
.setIcon(android.R.drawable.ic_dialog_alert)
.show();
}}, 3000);
}});
c.setOnClickListener(new View.OnClickListener(){
public void onClick(View v){
finish();
}});
}
static String getVersion(Context c)
{
try {
return c.getPackageManager().getPackageInfo(c.getPackageName(),0).versionName;
} catch(Exception e) {
return c.getString(R.string.unknown_version);
}
}
}
class LogTask extends AsyncTask<Void, Void, Void>
{
Activity activity;
String logText;
Process process;
ProgressDialog progress;
LogTask(Activity a, ProgressDialog p) {
activity = a;
progress = p;
}
@Override
protected Void doInVoid... v) {
try {
Log.e("crash", "doInBackground begin");
process = Runtime.getRuntime().exec(new String[]{"logcat","-d","-t","500","-v","threadtime"});
logText = UncaughtExceptionHandler.readFromLogcat(process.getInputStream());
Log.e("crash", "doInBackground end");
} catch (IOException e) {
e.printStackTrace();
Toast.makeText(activity, e.toString(), Toast.LENGTH_LONG).show();
}
return null;
}
@Override
protected void onCancelled() {
Log.e("crash", "onCancelled");
process.destroy();
}
@Override
protected void onPostExecute(Void v) {
Log.e("crash", "onPostExecute");
progress.setMessage(activity.getString(R.string.starting_email));
UncaughtExceptionHandler.sendLog(logText, activity);
progress.dismiss();
activity.finish();
Log.e("crash", "onPostExecute over");
}

复制代码

最主要的地方是doInBackground函数，这个函数通过logcat获取了崩溃信息。不要忘记在AndroidManifest.xml添加读取LOG的权限

[html] view plain copy print ?

<uses-permissionandroid:name="android.permission.READ_LOGS"/>

复制代码

3、获取到错误日志后，就可以写到sd卡（同样不要忘记添加权限），或者是上传。代码很容易google到，不多说了。最后再说下如何解析这个错误日志。

我们在获取到的错误日志中，可以截取到如下信息：
[plain] view plain copy print ?

12-12 20:41:31.807 24206
24206 I DEBUG :
12-12
20:41:31.847 24206 24206 I DEBUG : #00 pc 004931f8
/data/data/org.cocos2dx.wing/lib/libhelloworld.so
12-12 20:41:31.847 24206 24206 I
DEBUG : #01 pc 005b3a5e /data/data/org.cocos2dx.wing/lib/libhelloworld.so
12-12
20:41:31.847 24206 24206 I DEBUG : #02 pc 005aab68
/data/data/org.cocos2dx.wing/lib/libhelloworld.so
12-12 20:41:31.847 24206 24206 I
DEBUG : #03 pc 005ad8aa /data/data/org.cocos2dx.wing/lib/libhelloworld.so
12-12
20:41:31.847 24206 24206 I DEBUG : #04 pc 005924a4
/data/data/org.cocos2dx.wing/lib/libhelloworld.so
12-12 20:41:31.847 24206 24206 I
DEBUG : #05 pc 005929b6 /data/data/org.cocos2dx.wing/lib/libhelloworld.so

复制代码

[plain] view plain copy print ?

004931f8

复制代码

这个就是我们崩溃函数的地址， libhelloworld.so就是崩溃的动态库。我们要使用addr2line对这个动态库进行解析（注意要是obj/local目录下的那个比较大的，含有符号文件的动态库，不是Libs目录下比较小的，同时发布版本时，这个动态库也要保存好，之后查log都要有对应的动态库）。命令如下：

arm-linux-androideabi-addr2line.exe -e 动态库名称崩溃地址
例如：
[plain] view plain copy print ?

$
/cygdrive/d/devandroid/android-ndk-r8c-windows/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-addr2line.exe
-e obj/local/armeabi-v7a/libhelloworld.so 004931f8

复制代码

得到的结果就是哪个cpp文件第几行崩溃。如果动态库信息不对，返回的就是 ?:0

原文来自： http://www.cnblogs.com/lancidie/archive/2013/04/13/3019349.html

转载于:https://blog.51cto.com/zgame/1222624

crash report相关推荐

CentOS 6.2 虚拟机 mail邮件信息： crash：[abrt] full crash report
如下看到的mail的日志: [root@aldap1 openldap]# mailx >U 1 user@localhost.sysu. Mon Jun 18 22:35 214/1271 ...
分析Crash report
分析Crash report Apple的官方文档:Understanding and Analyzing iOS Application Crash Reports iOS设备上,当app崩溃时会创 ...
了解和分析iOS Crash Report
翻译自苹果官方文档:Understanding and Analyzing Application Crash Reports nimo: 这篇长达1w多字的文章,大概前后翻译了一个月,"写 ...
Ubuntu开机【OK】 Started LSBautomatic crash report generation卡死--已解决
Ubuntu开机[OK] Started LSB:automatic crash report generation卡死–已解决 [OK] Started Disk Manager [OK]Start ...
[Android crash report]Windows部署ACRA
[Android crash report]Windows部署ACRA ACRA全称为Application Crash Report for Android 安装安装Erlang,下载地址:htt ...
Kobe Bryant crash report
时间:太平洋时间2020年1月26日上午10点左右(北京时间1月27日凌晨两点左右) 地点:美国加利福尼亚州卡拉巴萨斯市洛杉矶县郊区Las Virgenes(拉斯维加斯)路飞机飞行轨迹及时间失事飞 ...
iOS平台一套完善的Crash Report解决方案
原文:http://blog.csdn.net/langresser_king/article/details/8593845 最开始想iOS和Android都做了,后面尝试了下android上面的崩 ...
get crash report binary image adress on ios
[ http://stackoverflow.com/questions/5567215/how-to-determine-binary-image-architecture-at-runtime ...
调试Release发布版程序的Crash错误
订阅调试Release发布版程序的Crash错误 http://dingchaoqun12.blog.163.com/blog/static/116062504201152834814661/ 在W ...

crash report

crash report相关推荐

最新文章

热门文章