- 1 FAQs concerning Integration and reporting in iOS
- 2 FAQs concerning Integration and reporting in Android
- 3 FAQs concerning Windows SDK Integration and reporting
- 4 FAQs concerning Unity SDK
- 5 FAQs concerning Unreal SDK
- 6 FAQs concerning stack retrace
FAQs
1 FAQs concerning Integration and reporting in iOS
1.1 Crashes are not reported after SDK Integration
● Check if the AppId is correct.
● Check if the SDK has been initialized before crashes.
● Check if there is an internet connection problem.
● If crashes were reported before testing but are no longer reported, CrashSight's data protection mechanism may have been triggered. Please uninstall the app and test again (real user crash accuracy won't be affected).
● Check whether another third-party component that can detect crashes is in use. It can be Firebase, Facebook, Google Mobile Ads, etc. There can be a compatibility issue. If you are using any of these components, please contact the administrator for help.
● Check whether the crashes were caused by iOS killing apps in the background. If the app was killed by the system, it wouldn't have time to handle and report the problem. This is usually triggered by long lags (more than 5 sec) and high CPU/GPU/memory usage within a certain period of time.
1.2 Why is Java Runtime Environment required for uploading symbol tables?
● Our symbol table extracting tool needs Java Runtime Environment. The symbol table tool only extracts required info.
1.3 The symbol table failed to be uploaded. It says the UUID doesn't match.
● A symbol table's UUID changes whenever it is built. Therefore, only the symbol table generated during the current build can be used to reproduce crashes happened after this build.
1.4 Dependency library extensions are different, such as: libc++.dylib and libc++.tbd
● When iOS SDK 9.0 and above are used to compile, dependency libraries with the libc++.tbd extension are added. When any other versions are used, dependency libraries with the libc++.dylib extension are added.
1.5 What are the features of different SDKs
● iOS SDK: Used to collect crashes and lags of iOS apps, compute app operation statistics, etc.
● Cocos Plugin: Used to collect crashes, script errors etc. of apps based on Cocos.
● Unity Plugin: Used to collect crashes, script errors etc. of apps based on Unity.
● Unity Plugin: Used to collect crashes, script errors, etc. of apps based on Unreal.
2 FAQs concerning Integration and reporting in Android
2.1 How to view the Logcat log of CrashSight during development?
● Refer to parameter configurations. During initialization, set the debugging mode to True.
2.2 Why does one user report hundreds of crashes in one day? Does it cost a lot of the user's data?
● There's a data cap for reports from a single user. Before the cap is reached, CrashSight will keep reporting.
2.3 Does every version need a symbol table?
● Yes.
2.4 Will reporting be affected if no symbol table is configured? How will it be affected?
● Configurations of symbol tables used for reproducing the issue don't affect reporting.
● If they are not configured, only the original crash stack will be displayed on the webpage, which doesn't help locating the issue much.
2.5 Crashes are not reported after SDK Integration
● Check if the AppId is correct.
● Check if the SDK has been initialized before crashes.
● Check if there is an internet connection problem.
● If crashes were reported before testing but are no longer reported, CrashSight's data protection mechanism may have been triggered. Please uninstall the app and test again (real user crash accuracy won't be affected).
In the release mode, there are 2 restrictions on reporting.
a. No more than one report in every 30 sec.
b. Only one report for the same stack.
● Check whether another third-party component that can detect crashes is in use. It can be Firebase, Facebook, Google Mobile Ads, etc. There can be a compatibility issue. If you are using any of these components, please contact the administrator for help.
● Check if the app was killed by the system due to insufficient memory (it happens a lot on low-end devices, and severe lags usually occur before the crashes).
3 FAQs concerning Windows SDK Integration and reporting
If crashes cannot be reported, please check the following in order:
- whether dll has been properly loaded;
- whether the setTQMConfig function has been executed;
- whether the crashes are supported by CrashSight (please note that throw and raise crashes are not supported);
- whether any TQM Center.exe process is running after initialization;
- whether the content of TQM64/GameBabyConfig.dat is the same as the GameBabyConfig.dat in the same directory as dll.
- After the crash, was any dmp file generated under TQM64/dump? If not, check 1-3
- After the crash, if a dmp has been generated, but no reporting has been seen on the "Crash Analysis" page, check 4-5
- If none of 1-7 applies, but crashes aren't reported, please add the following configurations to the 2 configuration files. Replace appid with project appid (remember to delete the configuration from the released version, or information will be leaked). After replacing, run the app to cause a crash. Send the log files in the two GBLog folders to the CrashSight developers for them to help solving the issue manually.
<LogOutput>appid</LogOutput>
4 FAQs concerning Unity SDK
4.1 Why still can't C# exceptions be detected and reported after initializing SDK?
a. Check if there are any other logics that have registered Application.RegisterLogCallback(LogCallback). Since LogCallback is implemented via unicast by default, only one callback instance can be maintained. You can call the CrashSightAgent.RegisterLogCallback(CrashSightAgent.LogCallbackDelegate) method to replace the registration of log callback;
b. Check if the SDK component of the corresponding platform has been integrated into the project
c. Check if the crashes for testing have been detected by the code
5 FAQs concerning Unreal SDK
5.1 FAndroidMisc::RequestExit isn't detected
According to UE's default way of handling, FAndroidMisc::RequestExit is a proper quitting in Android, instead of a crash. UE source code needs to be edited to change the exit call to abort call. iOS uses abort by default, so it can be detected and reported in iOS. 
6 FAQs concerning stack retrace
6.1 Stack isn't retraced in Android
Please make sure you've uploaded the symbol table and can see it displayed as uploaded from Crash Analysis->Individual Crash->Symbol Table. (No need to check if it's a Java symbol table file.)
Please make sure the uploaded symbol table isn't the original so. file, but a processed symbol table. Check Symbol Table Uploading Tool and How to Use It or Auto Upload Symbol Tables Using the BlueShield Plugin to see how to process and upload the table.
Please make sure the so. file uploaded in the previous step is a file containing symbols. Note that libunity.so of Unity doesn't usually contain symbols, and should be created using the libunity.sym.so file under the engine's directory or during compilation.
6.2 Stack isn't retraced in iOS
Similar to that on Android, please make sure you've uploaded the symbol table and can see it displayed as uploaded from Crash Analysis->Individual Crash->Symbol Table.
If a module not used by the project, such as the Foundation module, crashes, these are system modules. Symbol tables of system modules are managed together by CrashSight. Only some old versions and versions that have just been released may fail to be reproduced. If you encounter a reproduction issue concerning any other version, please contact the administrator.
6.3 Retraced again
After you've confirmed that the symbol table has been uploaded, you can click Reproduce Stack Again to reproduce the stack again.
6.4 Unreal Callback Function return TCHAR_TO_UTF8(*message)
TCHAR_TO_UTF8 macro definition can only be used on function parameters. Those smaller than 128 bytes use stack allocation, while those larger than 128 bytes use heap allocation. If larger than 128 bytes, releases the heap right after the semicolon and generates a wild pointer.
Correct usage:
char *recvbuffer = new char[200];
memset(recvbuffer, 0, 200);
strcpy(recvbuffer, TCHAR_TO_UTF8(*message));