Independent automatic crash detection software development kit

Abstract

The application is an independent automatic crash detection software development kit, which provides an improved SDK so that the SDK itself can determine whether the crash is related to it when the crash occurs. The SDK includes a set of APIs and a crash handler registered with the operating system. Each API is an interface accessible by computer software applications. Each API determines the current thread ID at the entry, and if the current thread ID is not in the list of thread IDs and their corresponding API call counters, it is inserted into the list. Each thread ID corresponds to an API call counter, which is incremented by 1 at the API entry and decremented by 1 at the API exit. The SDK also records the threads created internally. When a crash occurs, the crash handler is executed. If the crash thread belongs to the internal thread, it is determined that the crash is related to the SDK; otherwise, further determine whether the API call counter corresponding to the crash thread ID is greater than zero, and also determine that the crash is related to the SDK.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. patent application No. 17351331, filed June 18, 2021. Technical Field

[0003] The present invention relates to the field of software development tool kits, and in particular to a software development tool kit for independently and automatically detecting and identifying crashes. Background Art

[0004] Computer software applications typically use one or more third-party software development kits (SDKs) to implement certain functions and features. For example, with the rapid development of mobile computing on the Internet, many computer software applications (referred to as apps) have integrated third-party SDKs to provide real-time voice and video communication capabilities. An SDK is a computer software component that provides a certain function. Typically, many applications integrate SDKs, and the SDK runs on thousands or even millions of computers (such as smartphones, tablets, desktop computers, etc.). In some technologies, the application contains a computer program that forms part of the SDK; in other technologies, the application loads the SDK binary file at runtime. In either scenario, at runtime, the SDK runs in the application's computer process, and each computer process has its own virtual memory address space.

[0005] The application can be run on an operating system (such as and ) mobile devices, or a mobile application running on a computer with Microsoft Mac Software applications on computers with operating systems such as . Due to various reasons, applications may sometimes crash. When an application crashes, it stops running normally. At this time, the program crash needs to be handled immediately and correctly. Typically, SDK application crash handling relies on the crash diagnosis capabilities of the underlying operating system and / or application. However, the root cause of the crash may be the SDK itself. Because SDKs are integrated into a large number of applications and executed on multiple computers, a new method and SDK are needed to quickly determine whether a crash has occurred in the SDK or whether the crash is related to the SDK. This required new SDK should be able to quickly diagnose and determine the root cause of the crash. Summary of the Invention

[0006] In general, the present invention provides a software development kit (SDK). The SDK includes a first API (Application Programming Interface), which determines the thread identifier (ID) of the current thread at its entry. The current thread executes the first API. After being called, the first API can also increment a corresponding API call count counter based on the thread ID of the thread in which it is located, and decrement the counter by 1 before exiting the API. Furthermore, the SDK also includes a crash handler. The crash handler receives a crash ID from the operating system of the running computer, where the crash ID corresponds to a crash. The crash handler determines the crashing thread ID within the crash ID. If the crashing thread ID is in a list of thread IDs and corresponding API call counters, and the corresponding API call counter is greater than zero, the crash handler provides an SDK-related crash indicator, indicating that the crash was caused by the SDK. The SDK also includes a manager. The manager can be used to register the crash handler with the operating system. The SDK is loaded by a computer software application running on a computer. The crash handler provides the SDK-related crash indicator to a server application running on a server system via the Internet. The first API further determines whether the thread ID exists in a list consisting of thread IDs and their corresponding API call counters, which is initialized to empty; if the thread ID does not exist in the list, the thread ID and its corresponding API call counter are inserted into the list.

[0007] The SDK also includes a second API. The manager in the SDK creates an SDK internal thread. Each SDK internal thread contains an SDK internal thread ID. The manager stores all SDK internal thread IDs and maintains a set of SDK internal thread IDs. The crash handler checks whether the crash thread ID exists in the SDK internal thread ID set. If so, an SDK-related crash indicator is provided. The crash handler provides the SDK-related crash indicator to the server software application running on the server system via the Internet.

[0008] Furthermore, according to the present invention, a computer-implemented method for determining whether a program crash is SDK-related is proposed. The method is executed by the SDK and includes registering the SDK's crash handler with an operating system running on a computer. The SDK can be loaded by a computer software application running on the computer. The method also includes determining the thread ID of the current thread at a first API entry point of the SDK. The current thread runs a first API. The method also includes incrementing an API call counter corresponding to the thread ID by 1 after calling the first API; decrementing an API call counter corresponding to the thread ID by 1 before exiting the first API; and receiving a crash ID from the operating system running on the computer. The crash ID corresponds to a crash. The method also includes determining a crash thread ID from the crash ID; determining whether the crash thread ID exists in a list consisting of thread IDs and their corresponding API call counters; if so, and if the crash thread ID exists and its corresponding API call counter is greater than zero, providing an SDK-related crash indicator, indicating that the crash was caused by the SDK. The SDK-related crash indicator is provided to a server software application running on a server system via the Internet. The method further includes: determining whether the thread ID exists in a list of thread IDs and their corresponding API call counters; if the thread ID does not exist in the list, inserting the thread ID and its corresponding API call counter into the list. Furthermore, the method further includes: creating an SDK internal thread, where the SDK internal thread is identified by the SDK internal thread ID; storing the SDK internal thread ID and maintaining a set of SDK internal thread IDs; checking whether the crash thread ID exists in the set of SDK internal thread IDs; and if the crash thread ID exists in the set of SDK internal thread IDs, providing an SDK-related crash indicator. The SDK-related crash indicator is provided to a server software application running on a server system via the Internet. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] This patent or application file contains at least one drawing executed in color. Copies of this patent or application file with color drawing(s) will be provided by the Office upon request and payment of the applicable fee.

[0010] The technical features of the present invention will be particularly pointed out in the claims. The present invention itself, its construction and use can also be better understood by reference to the specification and the drawings which form a part thereof. In all the drawings, the same reference numerals represent the same parts:

[0011] Figure 1 FIG. 1 is a schematic block diagram of a communication system of an improved SDK running within an application program on multiple computers according to the present invention.

[0012] Figure 2A schematic block diagram of an improved SDK according to the present invention.

[0013] Figure 3 is a schematic block diagram of the improved SDK interacting with an operating system running on a computer according to the present invention.

[0014] Figure 4 FIG. 1 is a flow chart of a process of determining a crash source in a computer by an improved SDK according to the present invention.

[0015] Figure 5 1 is a schematic diagram of a process for forming a list of thread IDs and their corresponding API call counters and a set of thread IDs within an SDK according to the present invention.

[0016] Figure 6 FIG. 1 is a flow chart of a process of determining a crash source in a computer by an improved SDK according to the present invention.

[0017] Figure 7 1 is a schematic diagram of a list of thread IDs and their corresponding API call counters in an improved SDK according to the present invention.

[0018] Figure 8 FIG. 4 is a schematic block diagram of an API of an improved SDK according to the present invention.

[0019] It will be appreciated by those skilled in the art that, in order to clearly and simply illustrate the various components in the above drawings, the drawings are not necessarily drawn to scale. The sizes of some components in the drawings may be exaggerated relative to other components to aid understanding of the present invention. In addition, the specific order of certain elements, parts, assemblies, modules, steps, operations, events and / or processes described or illustrated herein may not be necessary in actual applications. It will be appreciated by those skilled in the art that, for simplicity and clarity, those useful and / or necessary elements that are well-known and easily understood in commercially available embodiments may not be described herein so that various embodiments of the present invention can be clearly presented. DETAILED DESCRIPTION

[0020] Figure 1 A schematic block diagram of a communication system, generally designated 100, is shown. Communication system 100 includes multiple participating computers, such as computers 102 and 104; a server system 130; and a database system 132 adapted for use with server system 130. Server system 130 comprises one or more server computers in a server farm or an internet cloud. Each server computer includes one or more processors; a memory having a certain capacity adapted for use with the processors; one or more network interfaces adapted for use with the processors to access a wide area network (e.g., the internet) 120 and database system 132; and an operating system.

[0021] Computers 102-104 are interconnected and communicate with server system 130 via wide area network 120. Each computer includes a processor, a memory with a certain capacity adapted to the processor, and a network interface adapted to the processor. Each computer may also include other interfaces adapted to the processor, such as a video input interface, a video output interface, an audio input interface, an audio output interface, and a user input interface (such as a keyboard, a touchpad, etc.). Each computer also runs a computer operating system, such as Figure 3 The operating system shown in 302.

[0022] Computers 102-104 can run applications, such as applications shown as 106 and 108. Applications 106-108 each access a new SDK 110 that provides crash self-detection functionality. The SDK 110 of the present invention runs within a computer process created for each application 106-108. Figure 2 .

[0023] Figure 2 is a schematic block diagram of the SDK 110 of the present invention. The SDK 110 of the present invention includes a crash handler 208; a set of APIs 202, 204, 206; and a manager 210. Applications 106-108 can call the SDK 110 through various APIs as interfaces to run various functions, provide data, process data, or provide other services. Each API defines its own characteristics so that the application can access it correctly. Different APIs can implement different functions. For example, the API can establish and maintain voice communication, video communication, data communication, text communication, and any combination of the above. Each component of the SDK 110 of the present invention is an integration of computer software programs encoded using one or more computer software programming languages ​​(such as C, C++, C#, Java, etc.).

[0024] exist Figure 3 In the example, when the SDK of the present invention is loaded or otherwise initialized on computer 102, manager 210 accesses operating system 302 to register crash handler 208. When a computer crash occurs, operating system 302 calls or otherwise uses crash handler 208 to identify the crash with specific data. This crash data is referred to as a crash ID in the present invention. In the crash identification process, operating system 302 serves as the crash management system for computers 102-104.

[0025] Figure 4 、 Figure 5 and Figure 6 FIG. 1 is a flowchart of the SDK 110 of the present invention determining whether a computer crash occurs within the SDK. Figure 4The process of collecting data to determine the source of a crash by the SDK 110 of the present invention is shown, generally indicated at 400. When the application 106 calls an API (such as API 202), it is said to have entered the API 202. At the entry point of the API 202, the API 202 determines the thread ID of the current thread at 402. The current thread refers to the thread of the program that is executing the API 202 when the API 202 is called. At 404, the API 202 checks whether the determined thread ID (i.e., the current thread ID) is already in the list of thread IDs and their corresponding API call counters maintained by the SDK 110 runtime. The list is detailed in Figure 7 , as a whole, is indicated at 700. List 700 includes a list of thread IDs 702 and their corresponding API call counters 704. When SDK 110 is first loaded at runtime, the list is empty. In some embodiments, list 700 is managed by the manager component 210 of SDK 110.

[0026] like Figure 4 As shown, if the thread ID is not in the list 700, then, at 406, the API 202 inserts the thread ID into the list 700, at which point the corresponding API call counter is set to zero. Then, at 406, the API call counter is set to 1. Alternatively, the API call counter may be set to 1 when the thread ID is inserted into the list 704. In this case, step 406 may be considered to have been executed. With respect to step 404, if the thread ID is already in the list 700 (e.g., Sc), then at 408, the API 202 increments the API call counter corresponding to the thread ID in the list 700 by 1. At 410, the API 202 performs the intended operation, such as sending or receiving data. At 412, before exiting from the API 202, the API 202 decrements the API call counter by 1 (the call counter was previously incremented by 1 at 406). Therefore, if no crash occurs within the API 202 while the computer 102 is running the API 202 , the value of the call counter should remain unchanged after the API exits the API 202 .

[0027] The SDK 110 of the present invention also provides a callback function. In other words, the application 106 can access the registration API provided by the SDK 110 to register a callback function. When certain conditions are met, the SDK 110 accesses or calls the callback function. When the computer 102 executes the callback function, a crash may occur. In this case, the SDK 110 needs to determine whether the crash is related to the SDK 110. The SDK 110's callback processing is detailed in Figure 5 .

[0028] For details about APIs (such as API 202), see Figure 8 . Figure 8 is a schematic block diagram of API 202. API 202 includes three components or parts, 802, 804, and 806. Component 802 is an API crash detection entry handler; component 804 is an API function handler, which provides the functionality that applications 106-108 expect API 202 to perform and provide; and component 806 is an API crash detection exit handler. In some embodiments, API crash detection entry handler 802 performs steps 402, 404, 406, and 408; the API function handler performs step 410; and the API crash detection exit handler performs step 412. Step 410 is performed after step 408 is completed, and step 412 is performed after step 410 is completed.

[0029] like Figure 5 As shown, Figure 5 5 is a schematic diagram of the formation process of two sets, namely the formation process of thread ID and its corresponding counter list (the overall process is represented by 510), and the formation process of internal thread ID set (the overall process is represented by 520). Figure 5 The upper middle part of the flowchart 510 is the process of forming a list of thread IDs and their corresponding counters: first, at 501, the SDK external module calls the SDK's API; at 503, the current thread ID is recorded; at 505, a counter corresponding to the current thread ID is created; at 507, the thread ID and its corresponding counter are saved; after multiple calls to the API by different threads, at 509, a list of thread IDs and their corresponding counters is formed. Figure 5 The lower half of flowchart 520 illustrates the process of generating an internal thread ID set: When the SDK calls a callback function, at 502, SDK 110 creates an internal SDK thread for processing the callback function. In some implementations, the manager component 210 creates the internal SDK thread, which performs certain functions, such as retrieving data from a network and providing it to the application 106 by calling the callback function. This thread can be created when SDK 110 is initialized or as needed. At 504, SDK 110 stores the internal SDK thread ID in memory.

[0030] When the computer 102 crashes, the operating system 302 calls the crash handler 208. The crash handler 208 processes the crash and determines whether the crash is related to the SDK 110. Figure 6As shown, the process as a whole is represented by 600. At 602, the crash handler receives a crash ID provided by the operating system 302. The crash ID is not necessarily an integer, it is a data set representing the crash. At 604, the crash handler 208 of the SDK 110 determines the thread ID of the thread that caused the crash from the crash ID. At 606, the crash handler 208 determines whether the crash thread ID exists in the SDK internal thread ID set. If so, at 608, the crash handler 208 provides an indicator (such as a message) indicating that the crash was caused by the callback function of the application 106, that is, the crash is related to the SDK. In some embodiments, the callback crash indicator is a message sent to the server software program running on the server system 130. The server software application processes the message and may also store it in the database 132.

[0031] With respect to step 606, if the crash thread ID is not in the set, then at 610, the crash handler 208 determines whether the crash thread ID exists in the list 700, and if so, determines whether its corresponding API call counter is greater than zero. If the crash thread ID exists in the list 700 and its corresponding API call counter is greater than zero, then at 612, the crash handler provides an SDK-related crash indicator. For example, the SDK internal crash indicator can be a message sent to a server software application or other recipient. With respect to step 610, if either of the two conditions is not met, then at 614, the crash handler 208 indicates that the crash is not related to the SDK 110. Step 614 is a non-essential step (optional step).

[0032] From the above description, it is obvious that the present invention is susceptible to many other modifications and variations. Therefore, it is noted that within the scope of the appended claims, the present invention may be practiced in ways other than as specifically described above.

[0033] The above description of the present invention is intended to better illustrate and explain, and is not intended to be exclusive or to limit the present invention to the specific forms described above. The above description is intended to better explain the principles of the present invention and the practical application of these principles, so that relevant technical personnel in this field can best utilize the present invention to implement various embodiments and make various modifications in the intended appropriate use. It should be recognized that the words "one" or "an" herein include both singular and plural forms. Conversely, where appropriate, references to multiple elements herein should also include their singular forms.

[0034] The scope of the present invention is not limited to the contents of the above description. Instead, the scope of protection is determined by the claims. Moreover, although the claims may be narrow, it should be recognized that the scope of the present invention is much broader than the scope of the claims. We will submit claims of broader scope in one or more applications claiming priority to this application. To the extent that portions of the disclosure in the above description and drawings are not included within the scope of the claims, such disclosure is not disclosed to the public, and we reserve the right to file one or more patent applications in the future for such additional disclosures.

Claims

1. A software development kit comprising: 1) A first API, the API: (a) determining, at an entry point of the first API, a thread ID of a current thread, the current thread running the first API; (b) After calling the first API, the API call counter corresponding to the thread ID is Increase by 1; as well as (c) before exiting the first API, reducing the API call counter corresponding to the thread ID by 1; 2) A crash handler, wherein: (a) receiving a crash ID from an operating system running on a computer, the crash ID corresponding to A crash; (b) determining the crash thread ID from the crash ID; (c) determining whether the crashed thread ID exists in a list consisting of thread IDs and their corresponding API call counters; as well as (d) if the crash thread ID exists in the list consisting of thread IDs and their corresponding API call counters, and the corresponding API call counter is greater than zero, providing an SDK-related crash indicator, where the SDK-related crash indicator indicates that the crash was caused by the SDK; 3) a manager, the manager registering the crash handler with the operating system, the SDK being loaded by a computer software application running on the computer; as well as 4) A second API, wherein: (a) The manager creates an SDK internal thread, and the SDK internal thread has an SDK internal thread ID; (b) The manager also stores the SDK internal thread ID and maintains the SDK internal thread ID gather; (c) The crash handler checks whether the crash thread ID exists in the SDK internal thread ID set; and (d) If the crash thread ID exists in the SDK internal thread ID set, the crash handler provides an SDK-related crash indicator.

2. The software development kit of claim 1 , wherein the crash handler provides the SDK to a server software application running on a server system via the Internet. Related crash indicators.

3. The software development kit according to claim 1, wherein the first API: 1) determining whether the thread ID exists in a list of pairs of thread IDs and their corresponding API call counters, wherein the list is initialized to be empty; and 2) If the thread ID is not in the list, the thread ID and its corresponding API A call counter is inserted into the list.

4. A computer-implemented method for determining whether a crash is related to a software development kit, the method being performed by the software development kit, comprising: 1) registering a crash handler of the SDK with an operating system running on a computer, the SDK being loaded by a computer software application running on the computer; 2) Determine the thread ID of the current thread at the first API entry of the SDK. The program runs the first API; 3) After calling the first API, increase the API call counter corresponding to the thread ID by 1; 4) Before exiting the first API, the API call counter corresponding to the thread ID is Decrease by 1; 5) Receive a crash ID from an operating system running on the computer, the crash ID corresponding to a Second crash; 6) Determine the crash thread ID from the crash ID; 7) Determine whether the crash thread ID exists in a list of thread IDs and their corresponding API call counters; as well as 8) If the crash thread ID is in the list of thread IDs and their corresponding API call counters, and the corresponding API call counter is greater than zero, then provide an SDK-related crash indicator, where the SDK-related crash indicator indicates that the crash was caused by the SDK; 9) Creating an SDK internal thread, where the SDK internal thread is identified by an SDK internal thread ID; 10) Storing the SDK internal thread ID and maintaining the SDK internal thread ID set; 11) Check whether the crash thread ID exists in the SDK internal thread ID collection; as well as 12) If the crash thread ID exists in the SDK internal thread ID set, the SDK-related crash indicator is provided.

5. The method according to claim 4, wherein Through the Internet to the server system The server software application running the SDK provides the SDK related crash indicators.

6. The method according to claim 4, further comprising: 1) determining whether the thread ID exists in a paired list of the thread ID and its corresponding API call counter; as well as 2) If the thread ID is not in the list, the thread ID and its corresponding API A call counter is inserted into the list.

Images