Patent Description:
<CIT> describes a system that allows application developers to track and monitor crashes that are occurring with their applications on various mobile devices. In some embodiments, the system includes an application programing interface (API) server that receives crash reports with raw crash data from the mobile devices and facilitates in assigning each crash report to one of several different crash processing servers. The crash processing server of some embodiments receives the raw crash data and translates obscure data in the raw crash data into a human or developer readable form.

The matter for protection is defined in independent method claim <NUM>, independent system claim <NUM> and independent computer program product claim <NUM>. Further preferred embodiments of the invention are defined in the dependent claims.

The present disclosure is directed to providing one or more portions of application error data, based on one or more errors that occur during execution of one or more applications, for use by third-party library development systems that develop third-party libraries used by these applications. According to techniques of the present disclosure, an application server system may be configured to process application error data associated with such errors occurring during execution of at least one application on one or more client computing devices, and outputting at least a portion of such data, which is included within library error data, to third-party library development systems. In such fashion, a library developer of one or more third-party libraries may receive and review such library error data, which may relate to the execution of corresponding library-dependent code that is included in or used by the applications during execution. By reviewing and analyzing library error data, third-party library developers and/or third-party library development systems may attempt to identify any coding faults or other issues in the third-party libraries that may have caused runtime errors during application execution.

In one example, a method includes receiving, by an application server system including one or more processors, and from one or more client computing devices, application error data associated with at least one error that occurred during execution of at least one application on the one or more client computing devices, receiving, by the application server system, mapping data that provides a mapping between (i) library-dependent source code of the at least one application and (ii) at least one third-party library from which the library-dependent source code is loaded during execution of the at least one application, and determining, by the application server system and based on the application error data and the mapping data, a match between the library-dependent source code and at least one portion of the application error data. The example method further includes, responsive to determining the match, attributing, by the application server system, the at least one error that occurred during execution of the at least one application to the at least one third-party library, generating, by the application server system, library error data associated with the at least one third-party library, wherein the library error data includes the at least one portion of the application error data, and sending, by the application server system and to at least one third-party library development system that develops the at least one third-party library, the library error data.

In another example, an application server system includes at least one processor and at least one computer-readable storage device configured to store instructions that are executable by the at least one processor to: receive, from one or more client computing devices, application error data associated with at least one error that occurred during execution of at least one application on the one or more client computing devices; receive mapping data that provides a mapping between (i) library-dependent source code of the at least one application and (ii) at least one third-party library from which the library-dependent source code is loaded during execution of the at least one application; determine, based on the application error data and the mapping data, a match between the library-dependent source code and at least one portion of the application error data; responsive to determining the match, attribute the at least one error that occurred during execution of the at least one application to the at least one third-party library; generate library error data associated with the at least one third-party library, wherein the library error data includes the at least one portion of the application error data; and send, to at least one third-party library development system that develops the at least one third-party library, the library error data.

In another example, a computer-readable storage device stores instructions that, when executed, cause at least one processor to perform operations. These example operations include receiving, from one or more client computing devices, application error data associated with at least one error that occurred during execution of at least one application on the one or more client computing devices, receiving mapping data that provides a mapping between (i) library-dependent source code of the at least one application and (ii) at least one third-party library from which the library-dependent source code is loaded during execution of the at least one application, and determining, based on the application error data and the mapping data, a match between the library-dependent source code and at least one portion of the application error data. The example operations further include, responsive to determining the match, attributing the at least one error that occurred during execution of the at least one application to the at least one third-party library, generating library error data associated with the at least one third-party library, wherein the library error data includes the at least one portion of the application error data, and sending, to at least one third-party library development system that develops the at least one third-party library, the library error data.

<FIG> is a block diagram illustrating an example distributed system <NUM>, including an application server system <NUM> that is configured to process application error data for use by one or more third-party library development systems <NUM>, in accordance with one or more aspects of the present disclosure. In the example of <FIG>, system <NUM> includes application server system <NUM>, one or more application development systems <NUM>, one or more third-party library development systems <NUM>, and one or more client computing devices <NUM>. Application server system <NUM>, application development systems <NUM>, third-party library development systems <NUM>, and client computing devices <NUM> may be communicatively coupled to one another via one or more networks <NUM>, which may include one or more wireless and/or wired networks.

Application server system <NUM>, application development systems <NUM>, and third-party library development systems <NUM> may each include one or more computing devices or servers, where each computing device or server includes one or more processors. Client computing devices <NUM> may also include one or more processors. Examples of client computing devices <NUM> include, but are not limited to, mobile phones, tablet computers, personal digital assistants (PDAs), laptop computers, portable gaming devices, portable media players, wearable computing devices (e.g., a watch, a wrist-mounted computing device, a head-mounted computing device), television platforms, or other type of computing devices. Application server system <NUM>, application development systems <NUM>, third-party library development systems <NUM>, and client computing devices <NUM> may each include one or more communication units (such as shown in <FIG>). These communication units may send data to and/or receive data from one or more other computing devices or systems. In some examples, the communication units support wireless and/or wired communication, and they may send and/or receive data using any variety of communication protocols.

As indicated earlier, client computing devices <NUM> are configured to execute any number of one or more applications <NUM> (e.g., mobile applications, games) over time. Various different application developers may use application development systems <NUM> to develop and distribute such applications <NUM>, which may then be executed by client computing devices <NUM>. In many cases, application development systems <NUM> may store local copies of applications <NUM> and may also distribute copies of applications <NUM> for storage on application server system <NUM>, as indicated in <FIG>. End users of client computing devices <NUM> may then download and execute applications <NUM> on client computing devices <NUM>, where such applications <NUM> may be developed by any number of different application developers using application development systems <NUM>. Applications <NUM> may perform various functions or access one or more services for client computing devices <NUM>. An e-mail application, a camera application, a calendar application, a messaging application, a social media application, a travel application, a game application, a stock application, and a weather application are all examples of applications <NUM>.

In certain situations, one or more of applications <NUM> may experience errors during execution on client computing devices <NUM>, and may even crash or abort execution in certain cases based on the severity or type of errors that occur. In these situations, when an application has an error or crashes during execution on one or more of client computing devices, the runtime system(s) of client computing device <NUM> may generate error reports that are transmitted to one or more of application server system <NUM> and/or application development systems <NUM> that are associated with the application. In such fashion, an application developer of the application may receive and review these error reports via application development systems <NUM> in an effort to identify any coding faults or other issues in the application that may have caused the runtime errors on client computing devices <NUM>.

In many cases, applications <NUM> include both application-dependent source code and library-dependent source code. Application-dependent source code is typically source code that has been developed (e.g., by application developers using application development system <NUM>) specifically for applications <NUM>. Library-dependent source code is typically library-based code that has been developed (e.g., by library developers using third-party library development systems <NUM>) for incorporation within third-party libraries <NUM> that may be incorporated in, or otherwise used by, various different ones of applications <NUM>. As a result, a large percentage of the source code for applications <NUM> may actually include library-dependent source code. The source code that causes applications <NUM> to experience errors and crashes during execution may, therefore, potentially include one or more portions of library-dependent source code that is included within applications <NUM>.

Faults that are present in such library-dependent source code may cause any of applications <NUM> that include such code to experience errors or even crash. Traditionally, and as noted above, application error data <NUM> associated with any errors in or crashes of applications <NUM> is provided only to application development systems <NUM> on which these applications <NUM> have been developed. However, this application error data <NUM> has not traditionally been provided to third-party library development systems <NUM>, such that library developers may have access to such application error data <NUM> and assess whether any of third-party libraries <NUM> developed by library developers may be the cause of the application errors or crashes.

Thus, according to techniques of the present disclosure, application server system <NUM> may be configured to process application error data <NUM> associated with errors occurring during execution of one or more of applications <NUM> on one or more of client computing devices <NUM>, and outputting at least a portion of such data, included in library error data <NUM>, to third-party library developers using third-party library development systems <NUM>. In such fashion, a library developer of one or more third-party libraries <NUM> may receive and review such library error data <NUM>, which may relate to the execution of library-dependent code from third-party libraries <NUM> that is included in applications <NUM> for execution. By reviewing and analyzing library error data <NUM>, third-party library developers and/or third-party library development systems <NUM> may attempt to identify any coding faults or other issues in third-party libraries <NUM> that may have caused the runtime errors during execution of applications <NUM> on client computing devices <NUM>.

As shown in <FIG>, and as described in further detail below, application server system <NUM> includes various functional modules. These include library error data generator <NUM>, application error handling module <NUM>, and library error reporting module <NUM>. Library error data generator <NUM> includes a library attribution module <NUM>, a scrubbing module <NUM>, a clustering module <NUM>, and an optional deobfuscation module <NUM>. These modules may individually or collectively perform operations described herein using any combination of software, hardware, and/or firmware residing in and/or executing at application server system <NUM>. Application server system <NUM> may execute these modules using one or more processors. In some cases, application server system <NUM> may execute these modules as one or more virtual machines executing on underlying hardware. In some cases, one of more of these may execute as a service of an operating system or computing platform.

As will be described in further detail below, application error handling module <NUM> of application server system <NUM> may receive, from application error reporting module <NUM> of client computing devices <NUM>, application error data <NUM> associated with at least one error that occurred during execution of one or more applications <NUM> on client computing devices <NUM>. Thus, application error reporting modules <NUM> are configured to send such application error data <NUM> associated with execution of applications <NUM> to application error handling module <NUM> of application server system <NUM>.

If one or more of applications <NUM> experiences a crash or other unexpected termination, application error data <NUM> may include application crash report data that is associated with the at least one error that caused one or more of applications <NUM> to crash. The application crash report data may include stack trace data that represents nested function invocations of applications <NUM>, where at least one portion of the application crash report data includes at least one portion of the stack trace data. The nested function invocations of the stack track data are those invocations that may have led, e.g., from a program loader to a location where a crash occurred during a respective execution of one or more of applications <NUM>. <FIG> illustrates one example of such stack trace data.

Application server system <NUM> also receives (e.g., from application development systems <NUM>) mapping data <NUM> that provides a mapping between (i) library-dependent source code of applications <NUM> and (ii) at least one third-party library of third-party libraries <NUM> from which the library-dependent source code is loaded during execution of application <NUM>. In some cases, application development systems <NUM> may provide application data <NUM> to application server system <NUM>, where application data <NUM> may include metadata associated with applications <NUM>. For instance, application data <NUM> may include mapping data <NUM>. Application data <NUM> may also include other information associated with applications <NUM>, such as application version number information, information associated with supported operating systems for applications <NUM> (e.g., version number(s) of one or more operating systems), information associated with supported device type(s) of client computing devices, deobfuscation data or files associated with code of applications <NUM>, and the like.

Application server system <NUM> determines, based on application error data <NUM> and mapping data <NUM>, a match between the library-dependent source code and at least one portion of application error data <NUM>. Library attribution module <NUM> of library error data generator <NUM> on application server system <NUM> may determine this match. When application error data <NUM> provided by application error reporting module <NUM> includes stack trace data, library attribution module <NUM> is configured to determine the match by matching, based on this stack trace data and mapping data <NUM>, one or more patterns of the library-dependent source code with one or more code locations in the at least one portion of the stack trace data. As a result, library attribution module <NUM> identifies a mapping between code in applications <NUM> and any of third-party libraries <NUM> from which the code is loaded. This mapping provides a mechanism by which library attribution module <NUM> determines whether a stack trace traverses any third-party library-dependent source code, such that library attribution module <NUM> can attribute one or more errors (e.g., an application crash) to identified ones of third-party libraries <NUM>.

Responsive to determining the match, library attribution module <NUM> attributes the at least one error that occurred during execution of applications <NUM> to the at least one third-party library included in third-party libraries <NUM>. Library attribution module <NUM> then generates library error data <NUM> associated with the at least one third-party library, where library error data <NUM> includes the at least one portion of application error data <NUM>. For example, if application error data <NUM> includes application crash report data, library error data <NUM> includes library crash report data that includes at least one portion of the application crash report data.

After library attribution module <NUM> generates library error data <NUM>, library error reporting module <NUM> of application server system <NUM> then sends, via networks <NUM> and to one or more of third-party library development systems <NUM> that develop the at least one third-party library, library error data <NUM>. The at least one third-party library is included in third-party libraries <NUM>. For example, library error reporting module <NUM> may send library error data <NUM> to one or more library console interfaces <NUM> of or associated with third-party library development systems <NUM>. Library console interfaces <NUM> may store library error data <NUM> locally on third-party library development systems <NUM> in some examples. Library console interfaces <NUM> may also output library error data <NUM> for display at one or more display devices <NUM>, such as shown in the example of <FIG>. Display devices <NUM> may, in some examples, include one or more of a liquid crystal display (LCD), a dot matrix display, a light emitting diode (LED) display, an organic light-emitting diode (OLED) display, a micro light-emitting diode (microLED) display, an active matrix organic light-emitting diode (AMOLED) display, e-ink, or similar monochrome or color display capable of outputting visible information to third-party developers using third-party library development systems <NUM>.

In some examples, library error reporting module <NUM> may include or provide an application programming interface (API) that is called by library console interfaces <NUM> in order to output library error data <NUM> for display at display devices <NUM>. Application server system <NUM> may be configured to transmit library error data <NUM> to third-party library development systems <NUM> via library error reporting module <NUM>. Third-party library development systems <NUM> may execute library console interfaces <NUM> to provide a graphical user interface (e.g., within a browser) that may output library error data <NUM> for display to one or more developers using display devices <NUM>. Library console interfaces <NUM> may, in some cases, comprise executable code that is provided by application server system <NUM> to third-party library development systems <NUM> for execution.

In some cases, third-party library development systems <NUM> may also store library data <NUM>, which may include metadata associated with third-party libraries <NUM>. For instances, as will be described further in reference to <FIG>, library data <NUM> may include deobfuscation data that is usable by an optional deobfuscation module <NUM> of application server system <NUM> to deobfuscate one or more portions of application error data <NUM> (e.g., stack trace data) received from client computing devices <NUM>, and which is then used by library error data generator <NUM> to generate library error data <NUM>. This deobfuscation data is associated with library-dependent source code of applications <NUM>. In some cases, application data <NUM> provided by application development systems <NUM> to application server system <NUM> may also include deobfuscation data that is usable by deobfuscation module <NUM> to deobfuscate one or more portions of application error data <NUM>, where such deobfuscation data is associated with application-dependent source code of applications <NUM>.

In many cases, application error data <NUM> (e.g., stack trace data) provided by application error reporting module <NUM> may include application-specific data for applications <NUM>, and/or sensitive internal data associated with applications <NUM>. In addition, application error data <NUM> may have variability associated with execution errors of multiple different ones of applications <NUM>, because different applications may utilize potentially faulty library-dependent source code in different contexts. Furthermore, application error data <NUM> may, in some cases, include indications of library-dependent source code for multiple different ones of third-party libraries. As a result, in these cases, library error data generator <NUM> may determine to remove one or more portions of application error data <NUM> when generating library error data <NUM> that is provided to third-party library development systems <NUM>.

For example, a scrubbing module <NUM> of library error data generator <NUM> may be configured to remove all application-dependent information (e.g., application-dependent source code) from application error data <NUM> when generating library error data <NUM>. As a result, third-party library development systems <NUM> do not receive any such application-dependent information within library error data <NUM> for use or display by library console interface <NUM>.

For cases in which application error data <NUM> includes library-dependent source code for multiple different ones of third-party libraries <NUM> developed by third-party library development systems <NUM>, scrubbing module <NUM> may also be configured to remove one or more portions of such library-dependent source code when generating library error data <NUM>, such as any library-dependent source code not associated with an identified third-party library that library attribution module <NUM> attributes to the current error. For example, application error data <NUM> may have at least one portion of data that includes first library-dependent source code associated with a first third-party library of third-party libraries <NUM>, application error data <NUM> and may also have at least one portion of data that includes second library-dependent source code associated with a second third-party library of third-party libraries <NUM>. If library attribution module <NUM> attributes at least one error associated with application error data <NUM> to the first third-party library, scrubbing module <NUM> may remove the second library-dependent source code from application error data <NUM> (e.g., stack trace data) when generating library error data <NUM>, as illustrated in <FIG>.

As shown in <FIG>, library error data generator <NUM> also includes a clustering module <NUM>. As will be described in further detail below, in various examples, clustering module <NUM> may be configured to cluster portions of application error data <NUM> (e.g., stack trace data) generated by multiple different ones of applications <NUM> that may be developed by application development systems <NUM>. These applications <NUM> may be developed by different application developers. The clustered portions of application error data <NUM> may include a clustered or aggregated group of different application error reports, for example, which have similar features of characteristics. Because application error reporting modules <NUM> of client computing devices <NUM> are all configured to provide application error data <NUM> to application server system <NUM>, where application error data <NUM> is associated with errors occurring during execution of potentially multiple different applications <NUM> developed by different application developers, application server system <NUM> may be capable of aggregating and clustering such data into library error data <NUM>. As a result, library developers who develop third-party libraries <NUM> may view such aggregated and/or clustered information about libraries they develop via library console interface <NUM>.

For example, if multiple different ones of applications <NUM> developed by multiple different application developers each include a potentially faulty third-party library included in third-party libraries <NUM> provided by third-party library development systems <NUM>, one or more of these applications <NUM> may experience a similar error or crash during execution. As a result, similar application error data <NUM> may be generated when errors occur with such applications <NUM>, and clustering module <NUM> of application server system <NUM> may identify similar library-dependent source code in the portions of application error data <NUM> that correspond to each of the errors occurring during execution of these applications <NUM>. Library attribution module <NUM> may then then generate library error data <NUM> that includes clustered error data (e.g., stack trace data) that identifies the library-dependent source code associated with the potentially faulty third-party library. Library error reporting module <NUM> may send such library error data <NUM> to third-party library development systems <NUM>, such that the library developer of this library may view the library error data <NUM> using library console interface <NUM>. This library error data <NUM> may also include additional information that may be useful to the developer, such as the number of different applications experiencing errors when using this library, the type of client computing devices <NUM> used during application execution, the operating system(s) of client computing devices <NUM>, the application or library version numbers, and the like.

As outlined in further detail below, scrubbing module <NUM> may first remove application-dependent and/or other library-dependent source code information from application error data <NUM>, as described above, and clustering module <NUM> may then cluster similar application error data <NUM> for one or more applications into library error data <NUM>. In some cases, in order to identify similar features or characteristics of application error data <NUM> generated for different applications, clustering module <NUM> may generate fingerprint identifiers (e.g., hash identifiers) for portions of application error data <NUM> generated for different applications <NUM> in which errors occur, wherein these portions of application error data <NUM> may be stored or included in library error data <NUM>. Clustering module <NUM> may then cluster application error data <NUM> (e.g., in real-time, at one or more times during the day via batch processing of application error data <NUM>) when generating library error data <NUM>, based on matching fingerprint identifiers of these portions of the application error data <NUM>. For instance, using the example outlined above, multiple different applications <NUM> that include a potentially faulty third-party library may each be associated with portions application error data <NUM> that include or identify a similar portion of library-dependent source code for this library. Clustering module <NUM> may generate similar or matching fingerprint identifiers for these portions of application error data <NUM>, where the fingerprint identifier may identify or be associated with this portion of the library-dependent source code. Clustering module <NUM> may then include this portion of application error data <NUM> that includes or matches the library-dependent source code within library error data <NUM>. Library error data <NUM> may also include information indicating the number of applications that include this code and that experienced an error.

For example, clustering module <NUM> may determine a first fingerprint identifier associated with the at least one portion of the application error data included in library error data <NUM>. This at least one portion may include library-dependent source code. Clustering module <NUM> may also determine a match between the first fingerprint identifier and a second fingerprint identifier associated with previously generated library error data included in library error data <NUM>, where the previously generated library error data is associated with the at least one third-party library. This previously generated library error data also includes at least one portion of application error data (e.g. the same or similar library-dependent source code) associated with the at least one error that occurred during execution of one or more of applications <NUM> on client computing devices <NUM>. Responsive to determining the match, clustering module <NUM> may cluster the library error data with the previously generated library error data to generate clustered library error data within library error data <NUM>, where the clustered library error data is associated with the at least one third-party library. In some cases, and as will be described in further detail below, the clustered library error data indicates at least a number of applications affected by the at least one error. Library error reporting module <NUM> may then send the clustered library error data to third-party library development systems <NUM>.

In some cases, clustering module <NUM> may perform one or more application anonymization functions with respect to applications and application developers of application development systems <NUM>. For example, when including library error information within library error data <NUM> that is associated with one or more of applications <NUM>, clustering module <NUM> may refrain from including any specific or identifying information about the ones of applications <NUM> associated with library error data <NUM>. Instead, clustering module <NUM> may include only generic information about such applications <NUM>, such as the number of applications in general. In some cases, clustering module <NUM> may include further information, such as the type of application, one or more version numbers of the one or more third-party libraries <NUM>, application information, at least one version number of at least one operating system executed by client computing devices <NUM>, information about client computing devices <NUM> (e.g., operating system or device type information), and the like, depending on the type and detail of information included in application error data <NUM> that is provided to application server system <NUM> by client computing devices <NUM> (e.g., by application error reporting modules <NUM>). In addition, and as will be described in further detail below, clustering module <NUM> may also include one or more of the following within library error data <NUM>: a number of applications <NUM> affected by the at least one error over a period of time (e.g., <NUM> days, <NUM> days, all cumulative time to present, etc.), a number of users affected by the at least one error over the period of time, or a number of occurrences of the at least one error over the period of time.

In some cases, clustering module <NUM> may perform one or more application thresholding functions. For example, clustering module <NUM> may only include error data within library error data <NUM> that affects more than a threshold number of applications, to further potentially preserve the anonymity of the applications experiencing errors. In certain cases, only those errors (e.g., crashes) that are observed across more than this threshold number of applications may be reported to third-party library development systems <NUM>. These errors may relate to a common problem or bug that will be of particular interest to the library developer of the one or more third-party libraries associated with library error data <NUM>. Thus, in one or more examples, application server system <NUM> may determine that a number of applications <NUM> affected by the at least one error exceeds a threshold number, and library error reporting module <NUM> may only be configured to send clustered library error data <NUM> in response to determining that the number of applications affected by the at least one error exceeds the threshold number. In some cases, this threshold number may be a predetermined or default number of applications.

According to the techniques disclosed herein, the storage of certain data, such as application data <NUM>, library data <NUM>, application error data <NUM>, and/or library error data <NUM>, may only occur, in various examples, in response to a computing device or system (e.g., client computing devices <NUM> and/or systems <NUM>, <NUM>, <NUM>) receiving an affirmative consent or response from one or more users, such as one or more application or library developers, or end users. A user may be provided with controls allowing the user to make an election as to both if and when systems, programs, or features described herein may enable collection and/storage of information, and/or if and when systems, programs, or features described herein may enable transmission of content or communications between devices. In addition, and as described above, certain data (e.g., library error data <NUM>) may be treated in one or more ways before it is stored or used, so that identifiable information associated with applications <NUM> is removed.

<FIG> is a block diagram illustrating another example distributed system <NUM> including an application server system <NUM> that is configured to process application crash report data <NUM> for use by third-party software development kit (SDK) development systems <NUM>, in accordance with one or more aspects of the present disclosure. System <NUM> is one example of system <NUM>, where various components illustrated in <FIG> provide functionality that is similar to similarly numbered components illustrated in <FIG>.

For instance, system <NUM> includes one or more application server system <NUM> that are communicatively coupled, via one or more networks <NUM>, to one or more application development systems <NUM>, one or more SDK development systems <NUM>, and one or more client computing devices <NUM>. Application server system <NUM> is one example of application server system <NUM> shown in <FIG>; networks <NUM> are one example of networks <NUM>; application development systems <NUM> are one example of application development systems <NUM>; SDK development systems <NUM> are one example of third-party library development systems <NUM>; and client computing devices <NUM> are one example of client computing devices <NUM>.

<FIG> illustrates an example in which the third-party libraries include SDK's <NUM> that are developed by third-party SDK developers using SDK development systems <NUM>. In various examples, an SDK includes a collection of software development tools or components that are provided in an installable library. As shown in <FIG>, SDK development systems <NUM> include one or more SDK's <NUM>, which may be developed by one or more third-party SDK developers using SDK development systems <NUM>. Various different applications, such as applications <NUM> developed using application development systems <NUM>, may include one or more of SDK's <NUM>. Similar to third-party library development systems <NUM> of <FIG>, SDK development systems <NUM> in <FIG> include SDK's <NUM>, SDK data <NUM>, SDK crash report data <NUM>, one or more SDK console interfaces <NUM>, and one or more display devices <NUM>. SDK crash report data <NUM> is one example of library error data <NUM>, where one or more of the errors associated with execution of applications <NUM> include one or more application crashes. In some cases, SDK data <NUM> provided by SDK development systems <NUM> to application server system <NUM> may include deobfuscation data, as described earlier, which is associated with library-dependent source code of SDK's <NUM>. Application server system <NUM> may store such data locally in deobfuscation data <NUM>. Deobfuscation module <NUM> of SDK crash report generator <NUM> may use such deobfuscation data <NUM> to deobfuscate one or more portions of application crash report data <NUM> (e.g., library-dependent source code) in order for SDK crash report generator <NUM> to generate SDK crash report data <NUM>.

Similar to application development systems <NUM> shown in <FIG>, application development systems <NUM> of <FIG> include applications <NUM> and corresponding application data <NUM>, which includes mapping data <NUM>. One or more application developers may use application development systems <NUM> to create applications <NUM>. In some cases, application data <NUM> provided by application development systems <NUM> to application server system <NUM> may also include deobfuscation data, which is associated with application-dependent source code of applications <NUM>. Application server system <NUM> may store such data locally in deobfuscation data <NUM>.

Similar to client computing devices <NUM> shown in <FIG>, client computing devices <NUM> of <FIG> include applications <NUM>. One or more of applications <NUM> may crash or otherwise terminate execution, and application crash report data <NUM> may include data associated with these crashes. Application crash report data <NUM> is one example of application error data <NUM> shown in <FIG>. One or more application crash reporting modules <NUM> are configured to send application crash report data <NUM> to application server system <NUM>.

Application server system <NUM> includes applications <NUM> and corresponding application data <NUM>. Application data <NUM> includes mapping data <NUM> and optional deobfuscation data <NUM>. Application server system <NUM> also include SDK crash report generator <NUM>, application error handling module <NUM>, SDK crash reporting module <NUM>, application crash report data <NUM>, and SDK crash report data <NUM> (which are examples of library error data generator <NUM>, application error handling module <NUM>, library error reporting module <NUM>, application error data <NUM>, and library error data <NUM>, respectively).

Similar to library error data generator <NUM>, SDK crash report generator <NUM> includes an SDK attribution module <NUM>, a scrubbing module <NUM>, a clustering module <NUM>, and an optional deobfuscation module <NUM>. SDK crash report generator <NUM> is configured to generate SDK crash report data <NUM> based on application crash report data <NUM> that is sent by application crash reporting modules <NUM> and processed by application error handling module <NUM> of application server system <NUM>. Application crash report data <NUM> may include stack trace data <NUM> that is provided by application crash reporting modules <NUM>, and SDK crash report data <NUM> generated by SDK crash report generator <NUM> may also include stack trace data <NUM>. Stack trace data <NUM> may include one or more portions of stack trace data <NUM>, as described earlier in reference to library error data <NUM> and application error data <NUM> of <FIG>. SDK crash reporting module <NUM> of application server system <NUM> may send SDK crash report data <NUM> to SDK development systems <NUM>, which may then display one or more portions of this display at display devices <NUM>.

<FIG> is a block diagram illustrating an example application server system <NUM>, in accordance with one or more aspects of the present disclosure. Application server system <NUM> may be one example of application server system <NUM> (<FIG>) and/or application server system <NUM> (<FIG>). <FIG> illustrates only one particular example of application server system <NUM>, and many other examples of application server system <NUM> may be used in other instances. In various cases, application server system <NUM> may include a subset of the components shown in <FIG> or may include additional components not shown in <FIG>.

In the example of <FIG>, application server system <NUM> includes display device <NUM>, one or more processors <NUM>, one or more input components <NUM>, one or more communication units <NUM>, one or more output components <NUM>, and one or more storage devices <NUM>. Communication channels <NUM> may interconnect each of the components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and/or <NUM> for inter-component communications (physically, communicatively, and/or operatively). In some examples, communication channels <NUM> may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data between hardware and/or software.

One or more input components <NUM> of application server system <NUM> may receive input, such as input from a user. Examples of input are touch/tactile, presence-sensitive, and audio input. Examples of input components <NUM> include a presence-sensitive screen, touch-sensitive screen, touchscreen, mouse, keyboard, trackpad, voice responsive system, video camera, microphone or any other type of device for detecting input from a human or machine.

One or more output components <NUM> of application server system <NUM> may generate output. Examples of output are haptic, audio, and visual output. Examples of output components <NUM> include a presence-sensitive screen, a touch-sensitive screen, a touchscreen, a sound card, a video graphics adapter card, a speaker, a liquid crystal display (LCD), an organic light-emitting diode (OLED) display, a micro light-emitting diode (microLED) display, an active matrix organic light-emitting diode (AMOLED) display, a haptic device, or any other type of device for generating output to a human or machine.

One or more communication units <NUM> of application server system <NUM> may communicate with external devices via one or more networks by transmitting and/or receiving network signals on the one or more networks (e.g., one or more wired and/or wireless networks). For example, application server system <NUM> may use communication units <NUM> to transmit and/or receive radio signals on a radio network such as a cellular radio network. Likewise, communication units <NUM> may transmit and/or receive satellite signals on a satellite network such as a global positioning system (GPS) network. Examples of communication units <NUM> include a network interface card (e.g. such as an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device that can send and/or receive information. Other examples of communication units <NUM> may include short wave radios, cellular data radios, wireless Ethernet network radios, as well as universal serial bus (USB) controllers.

In some cases, application server system <NUM> may include a display device <NUM>. In some examples, display device <NUM> may provide output to a user using haptic, audio, or visual stimuli as described above with reference to output components <NUM>. For example, display device <NUM> may provide display or video output as described with reference to output components <NUM>. Display device <NUM> may also provide input capabilities such as that described above with reference to input components <NUM>. In some cases, application server system <NUM> may not include display device <NUM>.

One or more storage devices <NUM> may store information for processing during operation of application server system <NUM>. In some examples, storage devices <NUM> include temporary memory, meaning that a primary purpose of storage devices <NUM> is not long-term storage. Storage devices <NUM> on application server system <NUM> may be configured for short-term storage of information as volatile memory and therefore not retain stored contents if powered off. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art.

Storage devices <NUM>, in some examples, include one or more computer-readable storage media. Storage devices <NUM> may be configured to store larger amounts of information than volatile memory. Storage devices <NUM> may further be configured for long-term storage of information as non-volatile memory space and retain information after power on/off cycles. Examples of non-volatile memories include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage devices <NUM> may store program instructions and/or data associated with one or more of applications <NUM>, application data <NUM>, mapping data <NUM>, library error data generator <NUM>, application error handling module <NUM>, library error reporting module <NUM>, application error data <NUM>, and library error data <NUM>, which may include examples of similarly numbered components or modules shown in <FIG>. Library error data generator <NUM> includes deobfuscation module <NUM>, library attribution module <NUM>, scrubbing module <NUM>, and clustering module <NUM>.

One or more processors <NUM> may implement functionality and/or execute instructions within application server system <NUM>. For example, processors <NUM> on application server system <NUM> may receive and execute instructions stored by storage devices <NUM> that execute the functionality of applications <NUM>, library error data generator <NUM> (including deobfuscation module <NUM>, library attribution module <NUM>, scrubbing module <NUM>, and clustering module <NUM>), application error handling module <NUM>, and/or library error reporting module <NUM>. These instructions executed by processors <NUM> may cause application server system <NUM> to store information within storage devices <NUM> during program execution.

<FIG> is a conceptual diagram illustrating example stack trace data <NUM> that includes both library-dependent source code and application-dependent source code, in accordance with one or more aspects of the present disclosure. Stack trace data <NUM> is one example of stack trace data <NUM> shown in <FIG>, which may be included in application crash report data <NUM> that is provided by to application server system <NUM> by client computing devices <NUM>. Stack trace data <NUM> is associated with at least one error that occurred during execution of, e.g., one of applications <NUM> shown in <FIG>. For purposes of illustration only, the related examples illustrated in <FIG> will be described in reference to system <NUM> shown in <FIG>.

As illustrated in <FIG>, stack trace data <NUM> includes an error identifier (e.g., exception identifier) <NUM> that identifies one or more errors associated with stack trace data <NUM>. Stack trace data <NUM> also includes multiple code portions: library-dependent source code <NUM>, application-dependent source code <NUM>, and library-dependent source code <NUM>. Stack trace data <NUM> may represents nested function invocations having an invocation order <NUM>, which may have led, e.g., from a program loader to a location where a crash occurred during a respective execution of one or more of applications (e.g., applications <NUM> shown in <FIG>). Invocation order <NUM> of function invocations that may have led to the possible crash is from bottom-to-top in the example of <FIG> (e.g., an order of library-dependent source code <NUM>, application-dependent source code <NUM>, and library-dependent source code <NUM>).

In various examples, each line of stack trace data <NUM> shown in <FIG> may be referred to as a frame or code location of the stack trace. In some cases, each frame or code location of the stack trace may indicate information associated with the source code (e.g., library-dependent or application-dependent source code) for that frame of the stack trace. For example, this information may include a library name or identifier. In some examples, the name or identifier may include a package name, a namespace name, a module name, or the like. In some examples, the information for each frame or code location may include additional information, such as one or more of a class name, a method name, and/or a function name, separately or in any combination. In some cases, each frame or code location of the stack trace may further indicate a file name of the file in which the source code is included, and/or the line number of the source code for that frame.

Application-dependent source code <NUM> is associated with code that is specific to, e.g., an application of applications <NUM>. Library-dependent source code <NUM> is associated with code from, e.g., a first SDK (named "examplehttp") of SDK's <NUM> shown in <FIG>. Library-dependent source code <NUM> is associated with code from, e.g., a second SDK named ("OS. app") of SDK's <NUM>, where "OS" may represent a name of an operating system in this particular example.

<FIG> is a conceptual diagram illustrating example mapping data <NUM> that provides a mapping between one or more portions of library-dependent source code of an application and at least one third-party library from which the library-dependent source code is loaded during execution of the application, in accordance with one or more aspects of the present disclosure. Mapping data <NUM> may be one example of mapping data <NUM> shown in <FIG> that is included in application data <NUM> provided by application development systems <NUM> to application server system <NUM>. The use of such mapping data may, in various cases, enable SDK crash report generator <NUM> to determine whether stack trace data, such as stack trace data <NUM>, traverses any library code of an application in applications <NUM>, such that SDK attribution module <NUM> may attribute a crash to the library corresponding to such code.

In some cases, application developers and/or application development systems <NUM> may develop or create mapping data <NUM>, which is associated with respective ones of developed applications <NUM> that are deployed onto application server system <NUM> shown in <FIG>. Application development systems <NUM> may provide such mapping data <NUM> (which is one example of mapping data <NUM> shown in <FIG>) to application server system <NUM>, for use by SDK crash report generator <NUM>. In some cases, application server system <NUM> may obtain one or more portions of mapping data <NUM> from one or more external sources or repositories (e.g., publicly accessible repositories providing such information about applications <NUM>).

As illustrated in <FIG>, mapping data <NUM> that provides a mapping between one or more portions of library-dependent source code of an application of applications <NUM> and at least one third-party library (e.g., SDK) from which the library-dependent source code is loaded during execution of the application. In <FIG>, example mappings are shown between identified portions or patterns of library-dependent source code and a first SDK ("examplehttp").

For example, mapping data <NUM> maps a first portion or pattern <NUM> of library-dependent source code of the application to an SDK identifier <NUM> of this first SDK. As shown in <FIG>, pattern <NUM> identifies library-dependent source code having a package name "okttp3" and a class name of "ExampleHttpClient. " The "*" wildcard character in pattern <NUM> indicates any functions/methods in library-dependent source code with this package and class name are mapped to SDK identifier <NUM>. Mapping data <NUM> maps pattern <NUM> of library-dependent source code to the first SDK having SDK identifier <NUM>. SDK identifier <NUM> identifies this first SDK ("examplehttp"), where SDK identifier <NUM> may identify an SDK name and also version number ("<NUM>.

Mapping data <NUM> also maps a second portion or pattern <NUM> of library-dependent source code to SDK identifier <NUM> of the first SDK. Pattern <NUM> identifies library-dependent source code having a package name "examplehttp" and a class name of "ExampleHttpClient$Builder. " The "*" wildcard character in pattern <NUM> indicates any functions/methods in library-dependent source code with this package and class name are mapped to SDK identifier <NUM>.

Mapping data <NUM> also maps a third portion or pattern <NUM> of library-dependent source code to SDK identifier <NUM> of the first SDK. Pattern <NUM> identifies library-dependent source code having a package name "examplehttp" and being associated with platform code having a class name of "OSPlatform. " The "*" wildcard character in pattern <NUM> indicates any functions/methods in library-dependent source code with this package and class name are mapped to SDK identifier <NUM>.

Mapping data <NUM> also maps a fourth portion or pattern <NUM> of library-dependent source code to SDK identifier <NUM> of the first SDK. Pattern <NUM> identifies library-dependent source code having a package name "examplehttp" and being associated with platform code having a class name of "Platform. " The "*" wildcard character in pattern <NUM> indicates any functions/methods in library-dependent source code with this package and class name are mapped to SDK identifier <NUM>. Thus, in the example of <FIG>, all of the portions or patterns <NUM>, <NUM>, <NUM>, <NUM> of library-dependent source code are mapped to the same, first SDK ("examplehttp").

<FIG> is a conceptual diagram illustrating example stack trace data <NUM> included in an SDK crash report that is provided to one or more SDK development systems <NUM>, in accordance with one or more aspects of the present disclosure. In various examples, SDK crash report generator <NUM> (e.g., using SDK attribution module <NUM>) may generate SDK crash report data <NUM>, which includes stack trace data <NUM> shown in <FIG>. SDK crash reporting module <NUM> may then send this SDK crash report data <NUM> to SDK development systems <NUM> for output to display devices <NUM>.

In various examples, and as described earlier, SDK attribution module <NUM> may attribute a crash to one or more SDK's included in SDK's <NUM>. These SDK's may include library-dependent source code that is the cause of this crash. SDK attribution module <NUM> may determine, based on stack trace data <NUM> (<FIG>) and mapping data (including mapping data <NUM> shown in <FIG>) a match between library-dependent source code of the application and at least one portion of stack trace data <NUM>. For example, based on mapping data <NUM> and stack trace data <NUM>, SDK attribution module <NUM> may identify a first SDK ("examplehttp") as a possible cause of the crash. In addition, based on stack trace data <NUM> and additional mapping data related to a second SDK ("OS. app"), which is not shown in <FIG>, SDK attribution module <NUM> may identify the second SDK as another possible cause of the crash. Thus, SDK attribution module <NUM> identifies these first and second SDK's as SDK candidates <NUM> that may have caused the crash. In some examples, one or more of such SDK candidates may be responsible for any given crash. Because the first SDK is located at the top of stack trace data <NUM> shown in <FIG>, SDK attribution module <NUM> may, in some cases, rank the first SDK as a first or potentially stronger candidate responsible for the crash in relation to the second SDK.

In order to identify these SDK candidates <NUM>, in various examples, SDK attribution module <NUM> may analyze the mapping data and attempt to match portions or patterns in such data (e.g., patterns <NUM>, <NUM>, <NUM>, <NUM> in mapping data <NUM>) with source code included in the frames or code locations of stack trace data <NUM> received from client computing devices <NUM>. Upon find one or more matches, SDK attribution module <NUM> may then identify the third-party libraries corresponding to the library identifiers in the mapping data (e.g., first SDK "examplehttp" associated with SDK identifier <NUM> in mapping data <NUM>) as libraries that may be potential causes of the crash.

In one or more particular non-limiting examples, SDK attribution module <NUM> may perform such a process to identify SDK candidates <NUM> based on the following pseudocode:
<IMG>.

In this pseudocode, the input_stack_trace may correspond to stack trace data <NUM>, where input_stack_trace. code_locations correspond to each frame or code location of stack trace data <NUM>. The mapping. library_patterns of the pseudocode may correspond to patterns <NUM>, <NUM>, <NUM>, <NUM> of mapping data <NUM>. As noted above, SDK attribution module <NUM> may analyze the mapping data and attempt to match portions or patterns in such data (e.g., patterns <NUM>, <NUM>, <NUM>, <NUM> in mapping data <NUM>) with source code included in the frames or code locations of stack trace data <NUM> received from client computing devices <NUM>. Upon finding such matches, SDK attribution module <NUM> may add each identified library (e.g., library identifier) to the set of matched_libraries (e.g., SDK candidates <NUM>).

After performing the match operations, SDK crash report generator <NUM> may generate stack trace data <NUM> shown in <FIG>, which is associated with the first SDK ("examplehttp") and second SDK ("OS. app"), and which is included in SDK crash report data <NUM>. Stack trace data <NUM> may include one or more portions of stack trace data <NUM>. SDK crash reporting module <NUM> may send this SDK crash reporting data <NUM>, including stack trace data <NUM>, to SDK development systems <NUM>.

For example, as shown in <FIG>, stack trace data <NUM> includes an error identifier <NUM>, library-dependent source code <NUM> associated with the first SDK ("examplehttp") of SDK's <NUM>, and library-dependent source code <NUM> associated with the second SDK ("OS. Error identifier <NUM> corresponds to error identifier <NUM> of stack trace data <NUM> in <FIG>, library-dependent source code <NUM> corresponds to library-dependent source code <NUM>, and library-dependent source code <NUM> corresponds to library-dependent source code <NUM>.

However, as shown in <FIG>, stack trace data <NUM> does not include application-dependent source code <NUM>. Instead, stack trace data <NUM> includes a generic or uniform placeholder <NUM>. <FIG> illustrates one or more "-" or "_" characters as placeholder <NUM>, although in other examples, any other form of symbol or alphanumeric characters (e.g., "<private>") may be used. As described earlier, in various cases, scrubbing module <NUM> may be configured to remove certain information from stack trace data <NUM> when generating library error data, such as stack trace data <NUM> shown in <FIG>.

For example, after identifying SDK candidates <NUM>, scrubbing module <NUM> may wipe sensitive or specific information associated with the identity or internal details of the application that crashed. Thus, in various cases, scrubbing module <NUM> may be configured to remove all application-dependent information (e.g., application-dependent source code <NUM>) from stack trace data <NUM> when generating stack trace data <NUM>, and replacing this information with placeholder <NUM>. As a result, SDK development systems <NUM> do not receive any such application-dependent information within SDK crash report data <NUM> for use or display by SDK console interfaces <NUM>.

SDK crash report generator <NUM> (e.g., using SDK attribution module <NUM> and/or clustering module <NUM>) may, in some cases, be configured to generate a unique fingerprint identifier (ID) <NUM>, such as a unique hash identifier, which is associated with the content of stack trace data <NUM>. Fingerprint ID <NUM> may be used for aggregating and/or clustering stack trace data <NUM> with other similar stack trace data that may be associated with other application crashes, as described in further detail below. SDK crash reporting module <NUM> may send this SDK crash reporting data <NUM>, including stack trace data <NUM>, to SDK development systems <NUM> that are associated with the first SDK ("examplehttp") and the second SDK ("OS. app") included in SDK's <NUM>. The SDK developers of these first and/or second SDK's may then review SDK crash reporting data <NUM> using SDK console interfaces <NUM>.

In other cases, however, scrubbing module <NUM> may further be configured to remove information from stack trace data <NUM> that is associated with other SDK's. Thus, in the example of <FIG> in which SDK attribution module <NUM> has identified first and second SDK's as SDK candidates <NUM>, scrubbing module <NUM> may generate two separate instances of stack trace data that are associated with the first and second SDK's. The first stack trace data may include only library-dependent source code associated with the first SDK, and the second stack trace data may include only library-dependent source code associated with the second SDK. Both the first and second stack trace data may be stored in SDK crash report data <NUM>. SDK crash reporting module <NUM> may send the portion of SDK crash report data <NUM> that includes the first stack trace data to the one or more of SDK development systems <NUM> that develop the first SDK of SDK's <NUM>, and SDK crash reporting module <NUM> may send the portion of SDK crash report data <NUM> that includes the second stack trace data to the one or more of SDK development systems <NUM> that develop with the second SDK. The respective SDK developers of these first and second SDK's may then review the respective first and second stack trace data associated with the application crash. <FIG> provide examples of such first and second stack trace data. By utilizing this approach, scrubbing module <NUM> is configured to remove SDK information about the second SDK when providing first stack trace data to the developer of the first SDK, and to remove SDK information about the first SDK when providing second stack trace data to the developer of the second SDK.

<FIG> is a conceptual diagram illustrating another example of stack trace data <NUM> included in an SDK crash report (e.g., SDK crash report data <NUM>) provided to one or more SDK development systems <NUM>, in accordance with one or more aspects of the present disclosure. In cases where stack trace data <NUM> of <FIG> includes library-dependent source code for multiple different ones of third-party libraries <NUM> developed by third-party library development systems <NUM> (<FIG>), scrubbing module <NUM> may be configured to remove one or more portions of such library-dependent source code when generating stack trace data <NUM>, such as any library-dependent source code not associated with an identified third-party library that library attribution module <NUM> attributes to the current error.

Thus, in the example of <FIG>, scrubbing module <NUM> removes all frames of stack track data <NUM> provided by client computing devices <NUM> that include application-dependent source code <NUM> and any library-dependent source code that is not associated with the first identified SDK (library) candidate "examplehttp. " Thus, scrubbing module <NUM> removes library-dependent source code <NUM> that is associated with the second identified SDK (library) candidate "OS. app" when generating or updating stack trace data <NUM>. As shown in <FIG>, stack trace data <NUM> includes error identifier <NUM> and library-dependent source code <NUM> associated with the first SDK candidate "examplehttp. " Clustering module <NUM> may also generate a unique fingerprint identifier <NUM> for stack trace data <NUM>, which may be used for clustering stack trace data <NUM> with other similar stack trace data associated with other application crashes, as described in more detail below.

<FIG> is a conceptual diagram illustrating another example of stack trace data <NUM> included in an SDK crash report (e.g., SDK crash report data <NUM>) provided to one or more SDK development systems <NUM>, in accordance with one or more aspects of the present disclosure. In cases where stack trace data <NUM> of <FIG> includes library-dependent source code for multiple different ones of third-party libraries <NUM> developed by third-party library development systems <NUM> (<FIG>), scrubbing module <NUM> may again be configured to remove one or more portions of such library-dependent source code when generating stack trace data <NUM>, such as any library-dependent source code not associated with an identified third-party library that library attribution module <NUM> attributes to the current error.

Thus, in the example of <FIG>, scrubbing module <NUM> removes all frames of stack track data <NUM> provided by client computing devices <NUM> that include application-dependent source code <NUM> and any library-dependent source code that is not associated with the second identified SDK (library) candidate "OS. app" Thus, scrubbing module <NUM> removes library-dependent source code <NUM> that is associated with the first identified SDK (library) candidate "examplehttp" when generating or updating stack trace data <NUM>. As shown in <FIG>, stack trace data <NUM> includes error identifier <NUM> and library-dependent source code <NUM> associated with the second SDK candidate "OS. " Clustering module <NUM> may also generate a unique fingerprint identifier <NUM> for stack trace data <NUM>, which may be used for clustering stack trace data <NUM> with other similar stack trace data associated with other application crashes.

As a result, scrubbing module <NUM> may generate two separate instances of stack trace data that are associated with these first and second SDK's. The first stack trace data may include only library-dependent source code associated with the first SDK, and the second stack trace data may include only library-dependent source code associated with the second SDK. In one or more particular non-limiting examples, scrubbing module <NUM> may perform a process to generate such stack trace data for different candidate SDK's, for inclusion in SDK crash report data <NUM> that is sent to SDK development systems <NUM>, similar to or based on the following pseudocode:
<IMG>.

In this pseudocode, matched_libraries are those SDK candidates <NUM>, namely the first SDK ("examplehttp") and the second SDK ("OS. This pseudocode creates separate first and second instances of stack track data for the first and second SDK's within the list of library_stack_traces. For example, scrubbing module <NUM> creates and adds first library stack trace data <NUM> (library_stack_trace) to the list of library_stack_traces, which includes library-dependent source code <NUM> for the first SDK within stack trace data <NUM>, which is generated from input stack trace data <NUM> (input_stack_trace). Scrubbing module <NUM> traverses each frame or code_location of stack trace data <NUM> to identify library-dependent source code <NUM> for the first SDK. Upon identifying such code, scrubbing module <NUM> adds or appends this code as library-dependent source code <NUM> into the first library stack trace data <NUM> (library_stack_trace) in the list. For any other library-dependent source code (e.g., library-dependent source code <NUM>) or any application-dependent source code (e.g., application-dependent source code <NUM>), scrubbing module <NUM> removes this code entirely in stack trace data <NUM>, as shown in <FIG>, or replaces such code with one or more uniform placeholders (e.g., "_" characters) (not shown in <FIG>).

Similarly, scrubbing module <NUM> creates and adds second library stack trace data <NUM> (library_stack_trace) to the list of library_stack_traces, which includes library-dependent source code <NUM> for the second SDK within stack trace data <NUM>, which is generated from input stack trace data <NUM> (input_stack_trace). Scrubbing module <NUM> traverses each frame or code_location of stack trace data <NUM> to identify library-dependent source code <NUM> for the first SDK. Upon identifying such code, scrubbing module <NUM> adds or appends this code as library-dependent source code <NUM> into the first library stack trace data <NUM> (library_stack_trace) in the list. For any other library-dependent source code (e.g., library-dependent source code <NUM>) or any application-dependent source code (e.g., application-dependent source code <NUM>), scrubbing module <NUM> removes this code entirely in stack trace data <NUM>, as shown in <FIG>, or replaces such code with one or more uniform placeholders (e.g., "_" characters) (not shown in <FIG>).

As noted above, clustering module <NUM> may also generate a unique fingerprint identifier <NUM> for stack trace data <NUM>, which may be used for clustering stack trace data <NUM> with other similar stack trace data associated with other application crashes. Clustering module <NUM> may similarly generate a unique fingerprint identifier <NUM> for stack trace data <NUM>, which may be used for clustering stack trace data <NUM> with other similar stack trace data associated with other application crashes. Clustering module <NUM> may, in various cases, store fingerprint identifiers <NUM> and <NUM> (e.g., in SDK crash report data <NUM> or in an associated data store).

Each of stack trace data <NUM> and <NUM> may be processed and clustered intro groups of similar data or reports based on the identified fingerprint identifiers <NUM>, <NUM> respectively. By performing one or more clustering operations using clustering module <NUM>, SDK crash report generator <NUM> may be configured to process application crash report data <NUM> associated with any number of different applications <NUM> developed by any number of different application developers on application development systems <NUM>, and to then aggregate and cluster similar errors and crashes that have occurred during execution of these applications <NUM>. SDK crash reporting module <NUM> may then output clustered SDK crash report data <NUM> associated with particularly identified SDK's <NUM> to SDK development systems <NUM>, which may then be displayed at display devices <NUM> via SDK console interfaces <NUM>, for review by respective SDK developers.

In various cases, to perform such aggregation or clustering, SDK crash report generator <NUM> and/or SDK crash reporting module <NUM> may store current and historical stack trace data within stack trace data <NUM> of SDK crash report data <NUM>, indexed or grouped according to fingerprint identifiers that are respectively associated with such stack trace data. Thus, as one example, SDK crash report generator <NUM> may store stack trace data <NUM> in stack trace data <NUM>. Clustering module <NUM> may also store, within SDK crash report data <NUM>, one or more other portions of application crash report data <NUM> received from application crash reporting modules <NUM> that are associated with the particular crash that resulted in stack trace data <NUM>. For example, if application crash report data <NUM> includes version number information for the operating system used by applications <NUM>, the version numbers of any SDK's included in applications <NUM>, the device type of client computing devices <NUM>, or the like, clustering module <NUM> may store such information within SDK crash report data <NUM>. In some cases, clustering module <NUM> may also obtain SDK version information from mapping data <NUM>. All of such information within SDK crash report data <NUM> and stack trace data <NUM> may be indexed or grouped according to fingerprint identifier <NUM>. In some cases, clustering module <NUM> may also obtain SDK version information and/or SDK name information from mapping data <NUM>, which it may then store in SDK crash report data <NUM>.

Similarly, SDK crash report generator <NUM> may store stack trace data <NUM> in stack trace data <NUM>. Clustering module <NUM> may also store, within SDK crash report data <NUM>, one or more other portions of application crash report data <NUM> received from application crash reporting modules <NUM> that are associated with the particular crash that resulted in the generation of both stack trace data <NUM> and stack trace <NUM> (e.g., version numbers of the operating system used by applications <NUM>, the version numbers of any SDK's included in applications <NUM>, the device type(s) of client computing devices <NUM>, or the like). This information within SDK crash report data <NUM> and stack trace data <NUM> may further be indexed or grouped according to fingerprint identifier <NUM>. In addition, and as will be described in further detail below, clustering module <NUM> may also include one or more of the following within SDK crash report data <NUM>: a number of applications <NUM> affected by the at least one error over a period of time (e.g., <NUM> days, <NUM> days, all cumulative time to present, etc.), a number of users affected by the at least one error over the period of time, or a number of occurrences of the at least one error over the period of time.

Over time, SDK crash report generator <NUM> may process further application crash report data <NUM> associated with additional errors or crashes encountered during execution of applications <NUM>. These may include one or more of applications <NUM> developed by one or more different application developers using application development systems <NUM>. SDK crash report generator <NUM> may generate additional stack trace data associated with these errors or crashes. Clustering module <NUM> may generate corresponding fingerprint identifiers for such stack trace data, and may compare these fingerprint identifiers with previously generated fingerprint identifiers associated with stack trace data and other data previously stored in SDK crash report data <NUM>. If there is a match of the fingerprint identifiers, clustering module <NUM> may perform one or more clustering operations to aggregate or cluster the current error or crash data with the previously collected data, where such clustering may indicate similarities between errors or crashes occurring over time in one or more applications <NUM> that utilize similar ones of SDK's <NUM>. SDK crash reporting module <NUM> may then output SDK crash report data <NUM> to SDK development systems <NUM>, such that individual SDK developers may view, via SDK console interfaces <NUM>, the portions of SDK crash report data <NUM> that correspond to the one or more of SDK's <NUM> that they have developed and that may be the cause of one or more application errors.

Clustering module <NUM> may store various forms of clustering information within SDK crash report data <NUM> based on the performed clustering operations. For example, clustering module <NUM> may include one or more of the following types of information within SDK crash report data <NUM> in association with the clustered data: the number of occurrences of similar errors (e.g., reports, issues, crashes) over a period of time, the number of applications (and/or users of applications) that have experienced similar errors, the name(s) of the library (e.g., SDK) associated with the errors, the library version(s), the operation system(s) and/or operating system version(s) of the computing devices on which the errors occurred, and/or the type of client computing device(s) on which the errors occurred. Upon receipt of such aggregated and/or clustered data within SDK crash report data <NUM>, SDK development systems <NUM> may use SDK console interfaces <NUM> to output one or more portions of such data at display devices <NUM>, which may be reviewed by the respective SDK developers of the SDK's in question. <FIG> provide examples of such output.

As indicated previously, in some cases, clustering module <NUM> may perform one or more application anonymization functions with respect to applications and application developers of application development systems <NUM>. For example, when including error information (e.g., clustered information) within SDK crash report data <NUM> that is associated with one or more of applications <NUM>, clustering module <NUM> may refrain from including any specific or identifying information about the ones of applications <NUM> associated with SDK crash report data <NUM>. Instead, clustering module <NUM> may include only generic information about such applications <NUM>, such as the number of applications in general. In some cases, clustering module <NUM> may include further information, such as the type of application, information about client computing devices <NUM> (e.g., operating system or device type information), and the like, depending on the type and detail of information included in application crash report data <NUM> that is provided to application server system <NUM> by client computing devices <NUM> (e.g., by application error reporting modules <NUM>).

In some cases, clustering module <NUM> may perform one or more application thresholding functions as, e.g., a further form of anonymization. For example, clustering module <NUM> may only include error data within SDK crash report data <NUM> that affects more than a threshold number of applications, to further potentially preserve the anonymity of the one or more applications <NUM> experiencing errors. In certain cases, only those errors (e.g., crashes) that are observed across more than this threshold number of applications may be reported to SDK development systems <NUM>. These errors may relate to a common problem or bug that will be of particular interest to the library developer of the one or more SDK's <NUM> associated with SDK crash report data <NUM>. In some cases, this threshold may include a predetermined or default number of applications.

<FIG> is a screen diagram illustrating an example graphical user interface <NUM> that may be displayed at one or more third-party library development systems based on data provided by an application server system, in accordance with one or more aspects of the present disclosure. For purposes of illustration only, <FIG> will be described in reference to SDK development systems <NUM> and application server system <NUM> shown in <FIG>.

As previously described, SDK crash reporting module <NUM> may send SDK crash report data <NUM> to SDK development systems <NUM>. One or more SDK console interfaces <NUM> of SDK development systems <NUM> may output one or more portions of such SDK crash report data <NUM> (e.g., in one or more graphical user interfaces), for display at one or more display devices <NUM>. As a result, one or more SDK library developers may review the information output by SDK console interfaces <NUM> to determine any issues with respect to the respective ones of SDK's <NUM> that they have developed or maintained. Graphical user interface <NUM> illustrated in <FIG> is one example of such a graphical user interface.

Graphical user interface <NUM> includes various information provided by clustering module of <NUM>. As also described previously, clustering module <NUM> may generate clustered library error data <NUM> and may similarly generate clustered SDK crash report data <NUM>. For example, when generating such clustered SDK crash report data <NUM> for one or more errors (e.g., crashes) that occur during execution of one or more of applications <NUM>, clustering module <NUM> may include various forms of clustered information with SDK crash report data <NUM>. For instance, clustering module <NUM> may include information such as the type of applications <NUM>, one or more version numbers of at least one of corresponding SDK's <NUM>, at least one version number of at least one operating system executed by client computing devices <NUM>, information about client computing devices <NUM> (e.g., operating system or device type information), and the like, depending on the type and detail of information included in application crash report data <NUM> that is provided to application server system <NUM> by client computing devices <NUM>. In addition, clustering module <NUM> may also include one or more of the following within SDK crash report data <NUM>: a number of applications <NUM> affected by the at least one error over a period of time (e.g., <NUM> days, <NUM> days, all cumulative time to present, etc.), a number of users affected by the at least one error over the period of time, and/or a number of occurrences of the at least one error over the period of time.

Graphical user interface <NUM> illustrated in <FIG> includes various examples of such information. The top-portion of graphical user interface <NUM> includes graphs <NUM>, <NUM>, <NUM> associated with occurrences of a particular error or crash over the last <NUM> days. In some cases, SDK console interfaces <NUM> may output these graphs based upon input received from one or more SDK developers provided at SDK development systems <NUM>. For instance, an SDK developer may provide user input as SDK console interfaces <NUM> requesting information within graphical user interface for the last <NUM> days. In other examples, the SDK developer may request information for other time periods (e.g., <NUM> days, cumulative all time).

Graph <NUM> shows a graphical representation of the number of reports (e.g., occurrences) of the specified crash plotted over time. For graph <NUM>, the x-axis denotes time in days, and the left-hand y-axis denotes the number of reports. Graph <NUM> shows a graphical representation of the number of affected users of the crash over time. For graph <NUM>, the x-axis denotes time in days, and the left-hand y-axis denotes the number of affected users. Graph <NUM> shows a graphical representation of the number of affected applications for the crash over time. For graph <NUM>, the x-axis denotes time in days, and the right-hand y-axis denotes the number of affected applications (e.g., the number of affected ones of applications <NUM>).

As illustrated in <FIG>, graphical user interface also includes further crash details <NUM>, which may include one or more open issues. In the example of <FIG>, crash details <NUM> may include information for one or more different points in time, or days. For example, with respect to the particular crash that has occurred a certain number of times over the last <NUM> days (represented by graph <NUM>), affecting a certain number of users (represented by graph <NUM>) and/or applications (represented by graph <NUM>), each line of crash details <NUM> may include detailed information for one point in time (e.g., one day) represented by graphs <NUM>, <NUM>, <NUM>. For instance, as illustrated in <FIG>, crash details <NUM> may identify or indicate, for each respective row that corresponds to a particular day, the name or identifier of the SDK associated with the crash, the first affected version number of the SDK, the number of affected users (for one point on graph <NUM>), the number of affected applications (for one point on graph <NUM>), and the number of reports of occurrences of the crash (for one point on graph <NUM>).

<FIG> is a screen diagram illustrating another example graphical user interface <NUM> that may be displayed at one or more third-party library development systems based on data provided by an application server system, in accordance with one or more aspects of the present disclosure. For purposes of illustration only, <FIG> will be described in reference to SDK development systems <NUM> and application server system <NUM> shown in <FIG>.

Graphical user interface <NUM> is another example of an interface that may be output for display at display devices <NUM> of SDK development systems <NUM> by SDK console interfaces <NUM>. SDK console interfaces <NUM> may output graphical user interface <NUM> for display upon receipt of SDK crash report data <NUM>, which may include clustered data generated by clustering module <NUM>, as described above.

The top-portion of graphical user interface <NUM> includes graphs <NUM>, <NUM>, <NUM> associated with occurrences of a particular error or crash over the last <NUM> days. Different occurrences of this particular crash, during execution of one or more of applications <NUM> over time, may be associated with one or more version numbers of a particular SDK included in or used by applications <NUM>, one or more version numbers of an operating system (OS) executed by client computing devices <NUM> during execution of applications <NUM>, and/or one or more device types of client computing devices <NUM> (e.g., device type based on manufacturer and/or model, device type based on physical characteristics of client computing devices <NUM>, and the like).

Graph <NUM> is a bar chart that displays the percentages of these occurrences of a particular crash or type of crash that are clustered by SDK version, where each bar represents a different SDK version number. The SDK developer of this particular SDK may review graph <NUM> to identify a breakdown of the different version(s) of the SDK that are associated with different occurrences of the same or similar crash over the last <NUM> days. Graph <NUM> is a bar chart that displays the percentages of occurrences of a particular crash or type of crash that are clustered by OS version, where each bar represents a different OS version number. The SDK version may review graph <NUM> to identify a breakdown of the different versions of the OS executed by client computing devices <NUM> associated with different occurrences of the same or similar crash over the last <NUM> days.

Graph <NUM> is a bar chart that displays the percentages of occurrences of a particular crash or type of crash that are clustered by device type of client computing devices <NUM>, where each bar represents a different device type. The SDK version may review graph <NUM> to identify a breakdown of the different device types of client computing devices <NUM> associated with different occurrences of the same or similar crash over the last <NUM> days.

Graphical user interface <NUM> also includes stack information <NUM>. Stack information <NUM> may, in various cases, include a graphical representation of stack trace data <NUM> included in SDK crash report data <NUM>. As illustrated in <FIG>, stack information <NUM> may include identifiers for an OS version and an SDK version associated with the displayed stack trace. For example, the stack trace may be associated with a particular version number of the SDK included in or used by an application that crashed, and a particular version number of the OS executed by one or more of client computing devices <NUM> during execution of the application. Stack information <NUM> also includes a textual representation of one or more portions of stack trace data <NUM>. For example, this textual representation may be one of error identifier <NUM> and library-dependent source code <NUM> included in stack trace data <NUM>, as shown in <FIG>. In this example, the particular SDK of SDK's <NUM> that may be associated with the occurrences of the crash is an "examplehttp" SDK.

<FIG> is a flow diagram illustrating example operations of a process <NUM> that is performed by an application server system, such as any of the application server systems illustrated in <FIG>, in accordance with one or more aspects of the present disclosure. For purposes of illustration only, the operations of <FIG> are described with reference to application server system <NUM> shown in <FIG>.

As shown in <FIG>, process <NUM> includes receiving (<NUM>), by application server system <NUM> (e.g., using application error handling module <NUM>), and from client computing devices <NUM>, application error data <NUM> associated with at least one error that occurred during execution of at least one application of applications <NUM> on client computing devices <NUM>. Process <NUM> includes receiving (<NUM>), by application server system <NUM>, mapping data <NUM> that provides a mapping between (i) library-dependent source code of the at least one application and (ii) at least one third-party library from which the library-dependent source code is loaded during execution of the at least one application. The at least one third-party library may be included in third-party libraries <NUM>.

Process <NUM> also includes determining (<NUM>), by application server system <NUM> and based on application error data <NUM> and mapping data <NUM>, a match between the library-dependent source code and at least one portion of application error data <NUM>, and, responsive to determining the match, attributing (<NUM>), by application server system <NUM> (e.g., using library attribution module <NUM> of library error data generator <NUM> of library error data generator <NUM>), the at least one error that occurred during execution of the at least one application to the at least one third-party library. Process <NUM> further includes generating (<NUM>), by application server system <NUM> (e.g., using library attribution module <NUM> and/or clustering module <NUM> of library error data generator <NUM>), library error data <NUM> associated with the at least one third-party library, where library error data <NUM> includes the at least one portion of application error data <NUM>, and sending (<NUM>), by application server system <NUM> (e.g., using library error reporting module <NUM>), and to one or more third-party library development systems <NUM> that develop the at least one third-party library, library error data <NUM>.

If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. In this manner, computer-readable media generally may correspond to (<NUM>) tangible computer-readable storage media, which is non-transitory or (<NUM>) a communication medium such as a signal or carrier wave.

By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other storage medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

Accordingly, the term "processor," as used herein may refer to any of the foregoing structures or any other structure suitable for implementation of the techniques described herein. In addition, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules.

Rather, as described above, various units may be combined in a hardware unit or provided by a collection of intraoperative hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.

It is to be recognized that, depending on the embodiment, certain acts or events of any of the methods described herein can be performed in a different sequence, may be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the method). Moreover, in certain embodiments, acts or events may be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors, rather than sequentially.

In some examples, a computer-readable storage medium includes a non-transitory medium. The term "non-transitory" indicates that the storage medium is not embodied in a carrier wave or a propagated signal. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in RAM or cache).

Claim 1:
A method comprising:
receiving (<NUM>), by an application server system (<NUM>, <NUM>, <NUM>) comprising one or more processors (<NUM>), and from one or more client computing devices (<NUM>), application error data (<NUM>) associated with at least one error that occurred during execution of at least one application (<NUM>) on the one or more client computing devices;
receiving (<NUM>), by the application server system, mapping data (<NUM>, <NUM>) that provides a mapping between (i) library-dependent source code of the at least one application and (ii) at least one third-party library from which the library-dependent source code is loaded during execution of the at least one application;
determining (<NUM>), by the application server system and based on the application error data and the mapping data, a match between the library-dependent source code and at least one portion of the application error data;
responsive to determining the match, attributing (<NUM>), by the application server system, the at least one error that occurred during execution of the at least one application to the at least one third-party library;
generating (<NUM>), by the application server system, library error data (<NUM>) associated with the at least one third-party library, wherein the library error data includes the at least one portion of the application error data; and
sending (<NUM>), by the application server system and to at least one third-party library development system (<NUM>) that develops the at least one third-party library, the library error data.