Four open source libraries QuincyKit + KSCrash for parsing tools for iOS Crash files

We know that iOS bug positioning attaches great importance to crash logs. At present, there are many crash log collection and management services available online. The more famous ones are Crashlytics, Flurry, and Youmeng. Most people probably use this. The QuincyKit + KSCrash that I want to talk about here is a pair of open source combination. It may not have various high-level functions of the former. The basic functions are still there, but they are more focused on the following use cases:

1) It is not convenient to access the external network, or most In the case of intranet testing
2) Quick response to the crash problem and quick positioning
3) You need to control the Crash Report yourself, instead of handing it over to others

Obviously , the first item is enough to exclude Crashlytics, Flurry, Umeng and the like Regarding item 2 ,

Flurry shows that the crash report delay is relatively large, at least 6 hours, and Crashlytics is slightly better, but their servers are abroad, and the web page is also slower to open. What I want to add here is that I hate that Crashlytics uploads the app binary and dSYM files every time the program is compiled, which is quite time-consuming when the network conditions are poor or the app is relatively large. There is another situation that I have experienced, that is, the development and testers are far apart. For example, the development is on the 5th floor, and the test is on the 1st floor. In the most primitive stage, the tester finds a crash problem and will send the test equipment to On the 5th floor, let developers use Mac analysis, think about this efficiency, it is self-evident.

The third point is actually relatively reluctant, and the crash log is not much confidential.

QuincyKit
believes that there are still some people who know QuincyKit, but I have seen relatively few related articles. My main reference before is Nico's "CrashReport Framework of QuincyKit" and "Fried Cold Rice, mention QuincyKit again".

QuincyKit, in a nutshell, is a crash report management solution for iOS and Mac OS X. About the introduction of QuincyKit, you can read Nico's article and know about it. It is really convenient for the application in the test period. You don't need to register the APP Key in advance. No matter how many applications you have, the Client of QuincyKit is integrated in the App. After the terminal, just send the crash log to the server side, and the server side will automatically classify and manage according to the App ID.

QuincyKit is divided into Server side and Client side. Its server side is written in php, and a complete environment can be built with a server that supports PHP5.2 or above, as well as Mysql and Apache, and it should be able to be completed on Mac/Linux/Windows systems. It seems simple, but in fact, it may be a bit troublesome for beginners who have never built a server environment. Don't worry, there is XAMPP, an artifact, to solve most of the troubles. At the beginning, I used XAMPP to build the basic environment, but I couldn't find the relevant notes, so I couldn't paste them here.

In addition, it should be noted that the web management interface of QuincyKit Server is relatively simple, for example, it does not even have the function of sorting by time. However, since it is open source, it cannot be too demanding. Those who know PHP can try to customize more advanced functions for themselves. .

What I want to say here about KSCrash
is that I only use the server side of QuincyKit, and I choose KSCrash for the client side. There may be many people who are relatively unfamiliar with KSCrash, which is not surprising. No one has introduced KSCrash in China. Why is it KSCrash, the reason, and listen to me slowly:

1) If I remember correctly, the crash report generated by the QuincyKit client always lacks the most critical line compared with the native crash report, while the crash report generated by the KSCrash client will put this critical line in the last line, And provide some additional information, which is very helpful for problem location. Most of the time, I can locate the problem just by looking at this last line.

2) QuincyKit basically stopped updating in early 2013, and KSCrash is still continuously updated. For us, the most important thing is to update the client side, such as considering the possibility of supporting Swift in the future. The server side is mainly used to manage the crash log, and the free and open source QuincyKit is enough to deal with it.

3) The crash report generated by the KSCrash client does not require the dSym symbol file in most cases, and you can see the function name. If the problem is obvious, it can be quickly located. However, the line number displayed by default is still wrong. If you need a specific line number, you have to use the dSym symbol file to parse the crash report. (This seems to be supported by the QuincyKit client)

The most critical point is point 1. I wonder if anyone will give up using QuincyKit because of this.

It should be noted that KSCrash is only a client side, and there is no server side itself. But this is also its flexibility, because it can connect to the free QuincyKit, the paid server such as Hockey, Victory, etc., and can also send the generated crash log by Email. This is just one of the features of KSCrash. For more key features of KSCrash, you can see the list below. I believe you will be pleasantly surprised:

* Supports on-device parsing and offline re-parsing
* The generated report format is fully compatible with the iOS native crash report format
* Support 32-bit and 64-bit mode (experimental)
* Can handle errors at the mach level, such as stack overflow
* Detect the real cause of uncaught C++ exceptions
* Detect the behavior of accessing zombie (zombie or deallocated) objects
* Restore the exception information of NSException in the case of zombie objects or memory overwrites
* Extract valid information about object exception calls (such as unrecognized occurrences) selector sent to instance 0xa26d9a0 exception)
* Supports multiple servers and provides convenient API interface
* Display stack content
* Diagnose the cause of crash
* Record more information than Apple's native crash report, use JSON format to store
* Support display user self Defined additional data

The crashes that KSCrash can handle are divided into the following categories:

* Mach kernel exceptions
* Fatal signals
* C++ exceptions
* Objective-C exceptions
* Main thread deadlock (experimental nature)
* Custom crashes (scripting language)

have been tested by me , the use of KSCrash currently has the following two problems:

1) In some cases, it will cause a deadlock (deadlock) crash, which usually occurs when the application is doing time-consuming operations. If such a problem occurs, you should try your best to Optimize your app to avoid time-consuming operations (maybe I have turned on the deadlock detection function, which is currently Unstable Features)
2) If the server that collects the crash report when restarting the app after a crash is unreachable, the previous crash report It will be discarded, and even if the network is restored, it will not be resent.

If anyone minds these problems, they can try to modify the open source code of KSCrash to achieve their own purposes.

It should be noted that when the app is released, it is recommended that you use Flurry, Crashlytics or Umeng. After all, you may be facing tens of thousands or even more users. You can add a switch to your app, turn on the switch to report the crash log using KSCrash during testing, turn off the switch before release, and use Crashlytics or other online crash report tools. Don't forget to add a switch status check in your checklist, so as not to forget.

Crash Log automatic parsing There is also a parsing side
for QuincyKit, or Mac side, because crash log parsing must be done on Mac. To parse the crash log collected on the QuincyKit Server side, you must execute a symbolicate.php script on the Mac computer on the parsing side. What it does is actually download the unparsed crash log on QuincyKit to the local, parse it in batches, and upload it back in batches. You can start a timed task to execute this script regularly, so you don't have to execute it manually every time.

But there is a problem. If you want to parse successfully every time, you need to have the index of the .app file and .app.dSYM file corresponding to the crash log on your Mac in advance. This index can be achieved through the mdimport command (the introduction of mdimport can be found here). However, there must be some people who think that it is very troublesome to manually execute the mdimport command for indexing. The best way is to use scripts to collude and automate the various processes.

An automated process I can think of is:
(1) Automatically build the version, generate the ipa file and dSYM.zip file
(2) The parsing end gets the ipa file and dSYM.zip file through the script, then copy it to the specified folder, decompress it, execute mdimport
(3) Start a scheduled task on the Mac computer on the parsing side, and execute symbolicate.php regularly.

After these three steps, you can ensure that what you will always see on the QuincyKit web page is the crash log after parsing.

After doing all this, if you have experienced the stage of manually executing the symbolicatecrash command to parse the crash log, you will know that one is in the sky and the other is underground.

When searching for information, I also found that the author of the article "Doutzen: Local symbolication for QuincyKit" made a Mac application to complete the work of the parsing side, simplifies the configuration, and realizes timing and automatic parsing. However, according to the comments, it should be incompatible with the Lion system, and it is estimated that it will not be compatible with the latest 10.9/10.10. Fortunately, the code is open source, and you can use it for your own use with a little modification for Mac development.

Others have written a QuincyKit-like server in Rails, providing an online service website holdbug.com, but the code doesn't seem to be open source, and the website can't be opened. It is estimated that the support is stopped. See the link here.