跳到主要内容

常见问题

1 iOS 接入、上报常见问题​

1.1 接入 SDK 后崩溃没有上报​

● 检查AppId是否设置正确；

● SDK 的初始化是否在Crash之前完成；

● 网络是否可用；

● 在测试时若之前有上报突然不上报了，可能是触发了CrashSight的流量保护机制，请卸载App后再测试（并不会影响真实用户Crash准确率）

● 是否有使用具有捕获Crash功能的其他第三方组件，包括但是不限于firebase/fackbook/google mobile ads. 某些情况下会存在兼容问题，如果使用了上述组件，请联系管理人员协助处理。

● 是否是触发了iOS的强杀机制导致的崩溃。系统强杀，APP内没有处理时间，无法上报。主要触发条件为长时间卡顿(约5s以上），或者一定时间内CPU/GPU/内存占用过高等情况。

1.2 上传符号表为什么需要java环境​

● 我们符号表提取工具依赖于java环境，符号表工具只提取必要的信息。

1.3 符号表上传失败提示uuid不匹配​

● 每次构建，符号表的uuid都会发生改变，所以需要当次构建生成的符号表文件才能还原当次构建后上传的crash。

1.4 依赖库后缀名不同如：libc++.dylib与libc++.tbd​

● 使用iOS SDK 9.0以上编译时添加依赖库libc++.tbd，9.0以下添加libc++.dylib

1.5 不同SDK的功能都有哪些​

● iOS SDK：用于收集iOS App的崩溃、卡顿，统计App的运营数据等

● Cocos Plugin：用于收集基于Cocos引擎的App中的崩溃，脚本错误等

● Unity Plugin：用于收集基于Unity引擎的App中的崩溃，脚本错误等

● Unreal Plugin：用于收集基于Unreal引擎的App中的崩溃，脚本错误等

2 Android 接入、上报常见问题​

2.1 开发过程中怎样查看CrashSight的Logcat日志​

● 参考参数配置，初始化时，设置调试模式为True。

2.2 为什么相同的用户一天上报了几百条Crash？会消耗用户流量吗？​

● 单一用户的上报是有流量限制的，在达到流量限制之前CrashSight都会正常上报。

2.3 每个版本都要配置符号表吗​

● 是的。

2.4 不配置还原符号表会影响异常上报吗？会有什么影响？​

● 还原符号表的配置并不会影响上报。

● 如果没有配置，网页端将只能显示原始的崩溃堆栈，不利于崩溃问题排查。

2.5 接入 SDK 后崩溃没有上报​

● 检查AppId是否设置正确；

● SDK 的初始化是否在Crash之前完成；

● 网络是否可用；

● 在测试时若之前有上报突然不上报了，可能是触发了crashsight的流量保护机制，请卸载App后再测试（并不会影响真实用户Crash准确率）

release模式下，上报有2个限制条件 a. 30秒内只会上报一次 b. 相同堆栈，只会上报一次

● 是否有使用具有捕获Crash功能的其他第三方组件，包括但是不限于firebase/fackbook/google mobile ads. 某些情况下会存在兼容问题，如果使用了上述组件，请联系管理人员协助处理。

● 是否因为内存不足而被系统强杀（这种情况常发生在低端机，发生前往往极度卡顿）。

3 Windows SDK 接入、上报常见问题​

  1. 无法上报崩溃：请依次检查下列情况

    1. 检查dll是否正确加载；
    2. 检查CS_ConfigCrashServerUrl函数是否已经执行，设置的url是否正确；
    3. 检查CS_InitWithAppId函数是否已经执行，设置的appid是否正确；
    4. 崩溃产生后，是否在CrashSight64/dump目录（旧版本为TQM64/dump）下生成dmp文件，如无，请检查2、3中函数是否被正确调用
    5. 崩溃产生后，生成了dmp，但是在“崩溃分析”页面没有看到上报，请检查appid和url是否正确设置
    6. 如果1-5均无问题，还是没有崩溃上报，或者解决不了遇到的问题，请在所有初始化代码之前调用CS_ConfigDebugMode(true)开启debug模式。添加后重新打包运行制造崩溃，这个配置会在应用程序exe文件同目录下生成CrashSightLog文件夹，请将里面的log文件发给CrashSight开发，人工协助排查问题

4 Unity SDK 常见问题.​

4.1 初始化SDK后，为什么仍然无法捕获上报C#异常？​

a. 检查是否有其他存在注册Application.RegisterLogCallback(LogCallback)的逻辑，由于系统默认LogCallback是单播实现，所以只能维持一个回调实例，你可以调用CrashSightAgent.RegisterLogCallback(CrashSightAgent.LogCallbackDelegate)方法来替代日志回调的注册；

b. 检查对应平台的SDK组件是否已经集成到项目中

c. 检查测试用的崩溃是否被代码内部捕获了

5 Unreal SDK 常见问题​

5.1 FAndroidMisc::RequestExit 不捕获​

FAndroidMisc::RequestExit 按照UE默认的处理方式，走的是安卓的正常退出，不是崩溃，需要修改UE源码，把exit调用替换成abort调用。iOS默认是abort退出，因此可以捕获上报。

6 还原常见问题​

6.1 安卓堆栈未还原​

  1. 请确认已经上传符号表，并且可以在崩溃分析->单条崩溃->符号表页面看到符号表文件已上传。（Java符号表文件可以不用关注）

  2. 请确认上传的符号表不是原始的so文件，而是经过处理的符号表。处理上传方法请查看符号表使用处理相关说明或者符号表蓝盾插件自动化上传 。

  3. 请确认上一步上传的so文件为带符号的文件。特别的Unity引擎的libunity.so通常是不带符号的，需要使用引擎目录下或者编译过程中的的libunity.sym.so文件进行制作。

6.2 iOS堆栈未还原​

  1. 与安卓类似,请确认已经上传符号表，并且可以在崩溃分析->单条崩溃->符号表页面看到符号表文件已上传。

  2. 非项目使用的模块崩溃，例如Foundation模块等，均为系统模块。系统模块的符号表由CrashSight统一管理，只有一些很旧的版本，上线时间极短的版本可能不会被还原，其他版本还原问题可与管理员联系。

6.3 重还原​

当确保符号表已上传后，可以通过点击“重试还原堆栈”对堆栈进行重新还原。

6.4 Unreal回调函数return TCHAR_TO_UTF8(*message)​

TCHAR_TO_UTF8宏定义只能由于函数参数，小于128字节在栈分配，大于128字节在堆分配；如果大于128字节，分号结束后，堆立即释放，产生野指针； 正确用法：

char *recvbuffer = new char[200];
memset(recvbuffer, 0, 200);
strcpy(recvbuffer, TCHAR_TO_UTF8(*message));