System and method for providing a watchdog timer to enable collection of crash data

CROSS-REFERENCE TO RELATED APPLICATIONS

0001The present application is a continuation of commonly assigned copending U.S. patent application Ser. No. 14/100,579, which was filed on Dec. 9, 2013, by Perry et. al, for SYSTEM AND METHOD FOR PROVIDING A WATCHDOG TIMER TO ENABLE COLLECTION OF CRASH DATA, which is hereby incorporated by reference.

BACKGROUND INFORMATION

0002Certain mobile operating systems, such as iOS available from Apple, Inc. include operating system imposed timeout periods for applications executing on the mobile device. Typically, these operating system timeout periods are designed to ensure that if an application encounters an error condition that does not cause a crash, but instead results in the application entering a hung state for a predefined period of time, the mobile operating system terminates the application. Typically, these timeout periods are associated with certain predefined operations of an application, e.g., the initial launching of an application, the act of moving the application to the background and/or returning the application to the foreground. For example, it has been noted that iOS will typically terminate an application if the application has not completed its initial launching procedure within approximately 20 seconds.

0003While the termination of applications that have exceeded the mobile operating system's timeout period may work to ensure stability of the mobile device by preventing applications from hanging, the abrupt termination of the application by the mobile operating system provides a challenge for application developers to obtain debugging information that may be utilized to determine the cause of the application hanging. For example, application developers may include debugging software that detects when a conventional error condition (i.e., crash) occurs and records certain state information that may be used later for debugging purposes. However, the mobile operating system's abrupt termination of an application that exceeds the timeout period does not enable the debugging software to collect state information associated with the application. In these cases, the application developer receives no information relating to the crash.

SUMMARY OF THE INVENTION

0004The present invention relates generally to application debugging and more particularly to collecting state and crash data that may be later provided to a developer of an application The present invention overcomes the disadvantages of the prior art by providing a system and method for providing a watchdog timer to enable collection of crash data in applications that reach a mobile operating system's timeout period. In one aspect, the invention relates to a watchdog thread that is associated with a source thread of an application. Upon initiating an operation with which a timeout period is associated, the source thread initiates the watchdog thread. The watchdog thread constructs an asynchronous semaphore that is then passed to the source thread with a request to be responded to upon completion of the operation.

0005In one embodiment, if the source thread has not completed the operation within a watchdog timeout period that is slightly shorter in duration than the mobile operating system's timeout period, the watchdog thread invokes a crash function that causes crash data relating to the state of the device and application to be collected. In a second embodiment, the watchdog thread collects state data associated with the application at regular intervals so that in the event of the mobile operating system terminating the application, state data has been collected relating to the operation of the application. In a third embodiment, the watchdog thread collects state data associated with the application at regular intervals; however, the watchdog thread is also configured to not invoke a crash function and permit the mobile operating system to terminate the application upon the expiration of the operating system timeout period.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numerals indicate identically or functionally similar elements, of which:

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic block diagram of an exemplary computing environment in accordance with an illustrative embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> is a schematic block diagram of an exemplary end user device in accordance with an illustrative embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart detailing the steps of a procedure for utilizing a watch dog timer in accordance with an illustrative embodiment of the present invention; and

<figref idref="DRAWINGS">FIG. 4</figref> is a schematic block diagram of an exemplary crash (state) data structure in accordance with an illustrative embodiment of the present invention.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

0011A computer network is a geographically distributed collection of entities interconnected by communication links and segments for transporting data between end nodes, such as personal computers, workstations, mobile devices etc. Many types of networks are available, ranging from Wi-Fi networks, cellular telephone networks, local area networks (LANs) to wide area networks (WANs). Wi-Fi is a mechanism for wirelessly connecting a plurality of electronic devices (e.g. computers, cell phones, etc.) A device enabled with Wi-Fi capabilities may connect to the Internet via a wireless network access point, as known to those skilled in the art. Cellular networks are radio networks distributed over large areas called “cells”, wherein each cell may be served at least one fixed-location transceiver known as a cell site or base station. When joined together, these cells may provide radio coverage over a wide geographic area. As known by those skilled in the art, this may enable a large number of portable transceivers (e.g., mobile phones), to communicate with each other. LANs typically connect the entities over dedicated communication links located in the same general physical location, such as a building or a campus. WANs, on the other hand, typically connect geographically dispersed entities for long-distance communication links, such as common carrier telephone lines, optical light paths, synchronous optical network (SONET), or synchronous digital hierarchy (SDH) links. The Internet is an example of a WAN that connects disparate networks throughout the world, providing global communication between entities on various networks. The entities typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as Transmission Control Protocol/Internet Protocol TCP/IP, Hypertext Transfer Protocol (HTTP), etc. In this context, a protocol consists of a set of rules defining how the entities interact with each other and how packets and messages are exchanged.

0012<figref idref="DRAWINGS">FIG. 1</figref> is a schematic block diagram of an exemplary computing environment <b>100</b> in accordance with an illustrative embodiment of the present invention. Computing environment <b>100</b> is centered around a network <b>105</b> that is illustratively operatively interconnected with a cellular network <b>110</b>. An end-user device <b>200</b>, described further below in reference to <figref idref="DRAWINGS">FIG. 2</figref>, may comprise a cellular telephone, a tablet or other mobile device. More generally, the end-user device <b>200</b> may comprise any computing platform in which the principles of the present invention may be implemented. As such, the description of end-user device <b>200</b> being a mobile device should be taken as exemplary only. Also operatively interconnected with the network <b>105</b> is an analytic processing server <b>115</b>. The analytic processing server may be further operatively interconnected with an application developer <b>120</b>. The analytic processing server <b>115</b> may comprise the functionality to examine collected crash or state information from applications for the purpose of debugging. The analytic processing server <b>115</b> may be configured to receive such information by incorporating analytic code into an application developed by an application developer <b>120</b>. One example of an analytic processing server <b>115</b> is described in U.S. patent application Ser. No. 13/323,166, entitled SYSTEM AND METHOD FOR DATA COLLECTION AND ANALYSIS OF INFORMATION RELATING TO MOBILE APPLICATIONS, the contents of which are hereby incorporated by reference.

0013<figref idref="DRAWINGS">FIG. 2</figref> is a schematic block diagram of an exemplary end the user device <b>200</b> in which the principles of the present invention may be implemented in accordance with an illustrative embodiment of the present invention. The end user device <b>200</b> illustratively comprises a mobile device such as, e.g., a cellular telephone, tablet computer, etc. However, it should be noted that in alternative embodiments of the present invention, the end-user device may comprise a non-mobile computing device such as a desktop computer, etc. As such, while this description is written in terms of the end-user device <b>200</b> comprising a mobile device, it should be noted that such description is exemplary only.

0014The end-user device <b>200</b> illustratively comprises a display <b>205</b>, a processor <b>210</b>, a cellular network card <b>215</b>, a network interface <b>220</b>, a storage device <b>225</b> and a memory <b>230</b> interconnected by a network bus <b>235</b>. Display <b>205</b> illustratively comprises a touchscreen that enables a user to view applications as well as provide input for applications executing on the end-user device <b>200</b>. The processor <b>210</b> may comprise the necessary elements and/or logic adapted to execute software programs and manipulate data structures. In alternative embodiments, processor <b>210</b> may comprise of a plurality of separate processors dedicated to particular functions. As such, the description of a single processor <b>210</b> should be taken as exemplary only.

0015The cellular network card <b>215</b> and the network interface <b>220</b> illustratively contain the mechanical, electrical and signaling circuitry for transmitting/receiving data over a cellular network and/or Wi-Fi network. The cellular network interface <b>215</b> and network interface <b>220</b> configured to transmit and/or receive data using a variety of different communication protocols, including, inter alia, TCP/IP, UDP, ATM, SONET, HTTP, wireless protocols such as 802.11, frame relay, Ethernet Fiber Distributed Data Interface (FDDI), etc. Notably, the network interface <b>140</b> may also be used to implement one or more virtual network interfaces, such as for virtual private network (VPN) access, as is known to those skilled in the art.

0016The storage device <b>225</b> may comprise any form of storage adaptable for use in an end-user device. Examples of storage devices may comprise, micro hard disks, removable media, such as memory stick, Flash RAM, etc. Illustratively, the watchdog thread <b>250</b> may be configured to store crash data <b>400</b>, described further below in reference to <figref idref="DRAWINGS">FIG. 4</figref>, in the storage device <b>225</b>. In one embodiment of the invention, the watchdog thread may collect periodic state information relating to the executing application <b>240</b> and store at least a portion of that state information in crash data <b>400</b>. Similarly in another embodiment, should the watchdog thread invoke a crash function due to the watchdog timer being exceeded, the crash function may store related state information in the crash data structure <b>400</b>. The application <b>240</b> may be configured to, upon initialization, detect whether crash data <b>400</b> exists for the application. In response to determining that crash data <b>400</b> exists that is associated with the application, the application may be configured to forward the crash data <b>400</b> to analytic processing server <b>115</b>. Such forwarding of crash data enables the analytic processing server <b>115</b> to receive state information relating to the application to be used for debugging purposes. Exemplary, the forwarding of the crash data may be performed on a background processed by the application depending upon network connectivity.

0017The operating system <b>235</b> may comprise a mobile operating system such as the Android operating system available from Google, Inc., the iOS operating system available from Apple, Inc., etc. Exemplary application <b>240</b> is stored within memory <b>230</b> of the end-user device <b>100</b> and is executed by processor <b>210</b>. Illustratively, the application <b>240</b> may have a plurality of threads including, for example, a source thread <b>245</b> and a watchdog thread <b>250</b>. The source thread <b>245</b> may illustratively comprise the main thread of the application <b>240</b> that contains the primary program control for the application. The watchdog thread <b>250</b> is illustratively utilized to implement the principles of the present invention in accordance with an illustrative embodiment thereof.

0018<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart detailing the steps of a procedure <b>300</b> for utilizing a watchdog timer in accordance with an illustrative embodiment of the present invention. The procedure <b>300</b> begins in step <b>305</b> where the user initiates the application <b>240</b>. A user may initiate an application by, for example, clicking on an icon associated with the application displayed to the user on display <b>205</b>. Alternatively, an application may be initiated by, e.g., selecting an option within another application that causes the initialization of the application. For example, a user may click on a video link in a first application (e.g., a web browser), which causes a second application (e.g., a video player) to be initialized to play the video. As will be appreciated by those skilled in the art, any technique for initializing application may be utilized in accordance with various alternative embodiments of the present invention.

0019In response to the initiation of the application, the main( ) procedure begins to initiate in step <b>310</b>. It should be noted that procedure <b>300</b> is written in terms of an initial launching of an application; however, in alternative embodiments, the principles of the present invention may be utilized for operations other than initialization. Examples of other operations that may be associated with mobile operating system timeout periods include, inter alia, moving an application to the background, moving an application to the foreground, etc. As such, while procedure <b>300</b> is written in terms of initializing an application, the principles of the present invention may be applied to the execution of other operations.

0020The source thread <b>245</b> then, in step <b>315</b>, initiates a watchdog thread <b>250</b> associated with the application <b>240</b>. The source thread may initiate the watchdog thread using conventional thread creation techniques. The watchdog thread <b>250</b> calculates an expected timeout value in step <b>320</b>. Illustratively, this expected timeout value is the mobile operating system's timeout value associated with the operation to be performed. This may vary by type of operation, e.g., a 20 second timeout period for application initialization, 10 second timeout period for moving to background, etc.

0021The watchdog thread then creates a watchdog queue step <b>325</b> and a semaphore for the source thread in step <b>330</b>. The asynchronous semaphore is sent to the source thread in step <b>335</b>. More generally, the watchdog thread sends a message to the source thread requesting that the source thread respond upon completion of the operation. As such, the description of utilizing a semaphore should be taken as exemplary only.

0022The source thread continues initializing in step <b>340</b>. Ideally, the source thread completes initialization in step <b>345</b> before the termination of the application by the operating system. In the event that the source thread completes the initialization in step <b>345</b>, the source thread then returns the semaphore to the watchdog thread in step <b>350</b>. More generally, the source thread responds to the initial message from the watchdog thread indicating that the operation has completed.

0023In one embodiment of the invention, the watchdog thread is configured to sample application state data at regular intervals while the source thread is executing the operation in step <b>360</b>. This collected state data may then be saved as crash data <b>400</b>. The crash data <b>400</b>, described further below in reference to <figref idref="DRAWINGS">FIG. 4</figref>, may be later transferred to an analytic processing server <b>115</b> for analysis to aid in debugging the application <b>240</b>.

0024In an other embodiment of the invention, the watchdog thread may not sample application data while the operation is being executed. Instead, the watchdog thread may sleep until either it receives the semaphore back from the source thread in step <b>355</b> or the watchdog timeout expires in step <b>365</b>. In the event of the watchdog timeout being reached, the watchdog thread then invokes a crash( ) function in step <b>370</b>. Illustratively, the crash( ) function is incorporated into the debugging modules of the application and is configured to collect state data and store at least a portion of the collected state data in a crash data structure <b>400</b>. The crash( ) function then causes the termination of the application.

0025In another embodiment of the invention, the watchdog thread may collect application data at regular intervals in step <b>360</b> but may take no action in the event of the watchdog timeout period being exceeded. In such a case, the operating system will terminate the application in step <b>375</b> when the operating system's timeout period is exceeded. However, even though the operating system has abruptly terminated the application, the watchdog thread had collected and saved state information in a crash data structure <b>400</b> that may be used for debugging purposes.

0026In accordance with an alternative embodiment of the invention, the collected state data may be transferred to the analytic processing server for use in computing watchdog timeout periods. That is, the collected state data may provide empirical data used in determining the watchdog timeout periods to be utilized. This may be advantageous in determining the timeout period, especially in the event that the developer of the mobile operating system does not publically disclose the operating system's timeout period.

0027As will be appreciated by those skilled in the art, various combinations and permutations of actions may be taken by the watchdog thread. Several specific examples have been described herein; however, it should be noted that these examples are not to be viewed as limiting. In one alternative embodiment, the watchdog thread, in response to the elapsed time of the source thread performing the predefined operation approaching a threshold that is less than the watchdog timeout period, may transmit a message to the source thread indicating that the watchdog timeout period is about to expire. In response, the source thread may skip certain steps in performing the operation. For example, if the operation is initializing the application, the source thread may not perform optional activities. This increases the chance that the source thread may complete the operation prior to either the watchdog timeout period or the operating system timeout period being exceeded. This alternative embodiment provides for an increased chance that the source thread may complete the operation and reduces the chance of the application being terminated early by either the mobile operating system of by invocation of a crash function by the watchdog thread.

0028<figref idref="DRAWINGS">FIG. 4</figref> is an exemplary schematic diagram of an exemplary crash data structure <b>400</b> that may be utilized with an illustrative embodiment of the present invention. The crash data structure <b>400</b> may be utilized by the application <b>240</b>, or any of its threads, including, e.g., the source thread <b>245</b> and/or watchdog thread <b>250</b>, to store various state information that is collected. Illustratively, the crash data structure <b>400</b> comprises a plurality of fields including, for example, a state field <b>405</b>, a list of running processes field <b>410</b>, memory usage field <b>415</b>, network address field <b>420</b>, network settings field <b>425</b>, physical orientation information <b>430</b>, a field for each process <b>435</b> which may include separate sub fields <b>440</b> for each thread and, in alternative embodiments, additional fields <b>445</b>.

0029It should be noted that the various descriptions and embodiments described herein are exemplary only. The aspects of the invention may be implemented in software, such as a non-transitory computer readable medium, hardware, firmware or any combination thereof. For example, a non-transitory computer readable medium can be configured with instructions to perform one or more of the steps as described in relation to procedure hundred. Further, while this description is written in references to particular operating systems and/or end-user devices, one skilled in the art will appreciate that the functionality may be implemented and differing environments. As such description of iOS environment operating on a mobile device should be taken as exemplary only.