Detailed Description
In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
For the sake of simplicity of the drawing, the parts relevant to the present invention are shown only schematically in the figures, which do not represent the actual structure thereof as a product. Additionally, in order to simplify the drawing for ease of understanding, components having the same structure or function in some of the drawings are shown schematically with only one of them, or only one of them is labeled. Herein, "a" means not only "only this one" but also "more than one" case.
It should be further understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
In this context, unless explicitly stated or limited otherwise, the terms "mounted," "connected," "coupled," and "connected" are to be construed broadly, and may, for example, be fixedly connected, detachably connected, or integrally connected, mechanically connected, electrically connected, directly connected, indirectly connected via an intervening medium, or communicate between two elements. The specific meaning of the above terms in the present invention will be understood in specific cases by those of ordinary skill in the art.
In addition, in the description of the present application, the terms "first," "second," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following description will explain the specific embodiments of the present invention with reference to the accompanying drawings. It is evident that the drawings in the following description are only examples of the invention, from which other drawings and other embodiments can be obtained by a person skilled in the art without inventive effort.
As shown in FIG. 1, the present invention provides one embodiment of a method of analyzing a subsystem crash, comprising the steps of:
In one aspect, the present invention provides a method for analyzing a subsystem crash, comprising the steps of:
S100, burying points in a kernel layer of the subsystem so as to acquire the burying points when the subsystem is halted.
Specifically, the terminal equipment comprises user equipment such as a mobile phone and a watch for an android system, and the subsystem comprises a Wifi related module (wcnss subsytem), a communication related module (modem subsytem) and a Sensor related module (adsp subsytem).
For example, when the subsystem crash occurs, the big data embedded point reporting is performed, that is, when the subsystem crash occurs, the big data platform of the web end is reported.
And S200, receiving the attribute data packet, and selecting a corresponding dump file to store for analyzing the crash of the subsystem.
Specifically, the web platform, i.e. the big data platform of the web end, is pushed to the user equipment for an attribute value, and a switch of the dump file of the collection subsystem is opened.
By way of example, through the attribute and the attribute value set by the web platform, the web platform receives the set fields (attribute and attribute value) through the network, the terminal device receives the fields sent by the web terminal through the network by using the server, then analyzes the received fields, and selects the corresponding subsystem dump file by itself through the corresponding attribute and attribute value. The dump file refers to a memory file when each subsystem is abnormal when the subsystem crash problem is analyzed.
In the embodiment, the problem that the subsystem is abnormal and difficult to reproduce is solved, meanwhile, the user equipment does not need to send reproduction, the maintenance cost after sale is reduced, and the daily use of the user is not affected when the subsystem is abnormal.
Example two
The invention provides a method for analyzing the crash of a subsystem, as shown in fig. 2, comprising the following steps:
Before the step S100 of burying the point at the kernel layer of the subsystem to obtain the buried point data when the subsystem crashes, the method further includes the steps of:
S000 sets the restart level of each subsystem of the user version in the terminal device to related.
Specifically, the restart level of the subsystem is set to be related, so that the purpose of the method is that when the subsystem is abnormal, the system cannot crash, and the corresponding subsystem can be restarted in the background. After the restart level is set to be related, the electronic file of the corresponding subsystem is generated when crash occurs. The reasons for subsystem crash can also be analyzed by these elf files.
The system sets two levels (system and related) for the subsystem restart itself, and the subsystem restart level set by the system default is system, but we need to set related to the level here, so as to collect the elf file when the subsystem is crash and the corresponding subsystem is abnormal.
When the subsystem is abnormal after the system level is set, the whole system is abnormal, the collection of the subsystem if files cannot be carried out, and the user cannot normally use the system. Although ramdump of the whole memory (when the whole system crashes at a certain time point, the information of the part of software crashes is stored in the memory) can be collected in this case, the size is consistent with the DDR size of the corresponding equipment, the memory data is very large, the whole ramdump file needs to be analyzed when the subsystem is abnormal, and the efficiency is very low.
In this embodiment, the restart level of each subsystem is set to be a related level, and when an abnormality occurs in a certain subsystem in the system, only the subsystem is restarted, and the whole system is not restarted due to the abnormality, so that the normal use of the system by a user is not affected. Meanwhile, the file of the abnormal sub-system can be collected, and the size of the file collected at the moment is far smaller than that of ramdump.
In this case, the embodiment ensures that only the corresponding subsystem is restarted when a certain subsystem crashes by setting the restart level to the related level, and the whole system is not restarted. On the one hand, the normal operation of the system can be ensured, the user experience is improved, and on the other hand, the size of the file collected under the condition is far smaller than that of ramdump files generated when the system is restarted, so that the subsequent abnormal analysis of the subsystem is more efficient and rapid.
Preferably, the step S100 of burying a point in a kernel layer of the subsystem so as to obtain the buried point data when the subsystem is dead, includes the steps of:
Transmitting the embedded point of the kernel layer to framwork layers of interface functions through android JNI communication, inserting the embedded point data into a launcher database through the frawork layers of interface functions, and transmitting the embedded point data to the webpage end in real time through the launcher database.
Preferably, the receiving the attribute data packet, selecting a corresponding dump file for saving, so as to analyze that the subsystem crashes, and includes the steps of:
analyzing and acquiring an attribute and an attribute value by utilizing the attribute data packet, selecting a dump file of the subsystem according to the attribute and the attribute value, and storing the dump file, wherein the dump file comprises a memory file when the subsystem is halted.
Preferably, the receiving the attribute data packet, selecting a corresponding dump file for saving, so as to analyze that the subsystem crashes, and includes the steps of:
And when the subsystem crashes again, automatically collecting the dump file of the subsystem based on the attribute data packet so as to analyze the subsystem crashes.
Specifically, after the first occurrence of the crash of the subsystem, the web platform provides the attribute data packet, namely the attribute and the attribute value, to the terminal device, so that a collection switch of the elf file of the subsystem is opened, and when the crash of the subsystem of the android system in the terminal device occurs again, the dump file in the elf format can be directly collected.
In this embodiment, the dump file collection switch is opened by the attribute data packet generated in advance, so that the dump file can be automatically collected by the subsequent subsystem generated crash, so as to improve the efficiency of analyzing the cause of the crash of the subsystem.
Preferably, after the receiving attribute data packet, selecting a corresponding dump file to save for analyzing the crash of the subsystem, the method includes the steps of:
and after the dump file is collected, compressing the dump file to generate a dump compressed file, storing the dump compressed file, and deleting the dump file.
In this embodiment, by compressing the dump file, the saving space can be reduced, and the cache space is saved, so as to avoid the incomplete saving of the dump file caused by insufficient cache space.
Example III
The invention provides a method for analyzing the crash of a subsystem, which is shown in fig. 3 and comprises the following steps:
when subsystem crash occurs, the restart level of the user version is set to related.
Specifically, before the subsystem crash occurs, the default is to set the restart level of the user version to be related, and the debug version to be system.
The User version generally refers to a formally released software version provided for a User, and the debug generally refers to an informal software version used for development and debugging.
For example, after the restart level of the User version subsystem is set to be related, when crash occurs in the subsystem, the whole android system is not affected, the system is still normally operated, and the subsystem is restarted in the background, so that the whole system is not restarted. The performance on the user experience is that the user is completely unaware of the machine anomalies and is generally not affected by the use of other functions by the user during the subsystem restart. The purpose of setting relate the level is that the system crashes and only reboots some of the subsystems, not all of the subsystems.
And when the subsystem crash occurs, reporting the big data embedded point, namely reporting the big data platform of the web side when the subsystem crash occurs.
Specifically, when the subsystem crash occurs, the embedded point of the kernel layer of the android system is generally transmitted to the framwork-layer interface function of the android system through android JNI communication. The frawork-layer interface function reinserts the uploaded data into a laboratory database, and finally the laboratory sends the uploaded data to the web end in real time through a network (wifi or data traffic).
The web platform pushes an attribute value to the user device and opens a switch to collect subsystem dump files (elf files).
Specifically, through the attribute and the attribute value set by the web platform, the web platform receives the set fields (attribute and attribute value) through the network, the terminal equipment receives the fields sent by the web terminal through the network, then analyzes the received fields, and selects the corresponding subsystem dump file by the user through the corresponding attribute and attribute value. The dump file refers to a memory file when each subsystem needed to analyze the crash problem of the subsystem is abnormal, and the file format is an elf file.
When the machine generates the subsystem crash again, dump files of the subsystem are automatically collected, and in order to reduce the occupied space of a user, the field files are compressed and then stored.
The compression mechanism is that after the dump file is collected, the dump file is compressed and the original file is deleted, and only the compressed file is reserved.
The developer pulls the dump file of the subsystem through the network by using the web end, and then analyzes the dump file.
Because the report device list of the generation subsystem is arranged on the web platform every day, when the device generates the subsystem crash again, the dump file can be pulled through the network by the hidden name of the web platform. Because the method mainly aims at the user equipment, the network is generally used for pulling, and the method can be used for obtaining the local adb pull file.
In the embodiment, the invention can analyze subsystem crash equipment which is not easy to reproduce in the market, solves the problems of the prior analysis, can meet the key dump log required by a developer for analyzing crash, and can excessively consume the data flow of a user.
The default subsystem restart level of the general equipment is system, KERNEL PANIC is caused after the subsystem generates crash, the whole machine is pulled and the performance of the user equipment is that the whole machine is restarted. Besides passing through ramdump of DDR, the analysis can be performed through the elf file of a specific subsystem, and when crash occurs to the subsystem, the restarting level of each subsystem in the android system is set to be related, so that system breakdown cannot be caused when the subsystem is abnormal, and the corresponding subsystem can be restarted in the background. After the restart level is set to be related, the electronic file of the corresponding subsystem is generated when crash occurs. The reasons for subsystem crash can also be analyzed by these elf files.
Example IV
Based on the above embodiment, as shown in fig. 4, the same parts as those of the above embodiment are not repeated in this embodiment, and this embodiment provides an embodiment of a method for analyzing a crash of a subsystem, which specifically includes the following steps:
Before the step S100 of burying the point at the kernel layer of the subsystem to obtain the buried point data when the subsystem crashes, the method further includes the steps of:
S000 sets the restart level of each subsystem of the user version in the terminal device to related.
Specifically, the restart level of the subsystem is set to be related, so that the purpose of the method is that when the subsystem is abnormal, the system cannot crash, and the corresponding subsystem can be restarted in the background. After the restart level is set to be related, the electronic file of the corresponding subsystem is generated when crash occurs. The reasons for subsystem crash can also be analyzed by these elf files.
Preferably, after the step S000 of setting the restart level of each subsystem of the user version in the terminal device to related, the method further includes the steps of:
S001, when the restarting level of the subsystem is set to be related and a crash occurs, the subsystem is restarted.
Preferably, after the step S000 of setting the restart level of each subsystem of the user version in the terminal device to related, the method further includes the steps of:
s002, when the restarting level of each subsystem is set to be related and the subsystem is crashed, generating a dump file of the subsystem.
Specifically, since the system includes a plurality of subsystems, the restart level of the subsystem is set to be related, when crash occurs in the subsystem, that is, when the subsystem is abnormal, all the subsystems cannot crash, and only the corresponding subsystem can be restarted in the background. After the restart level is set to be related, the electronic file of the corresponding subsystem is generated when crash occurs. The reasons for subsystem crash can also be analyzed by these elf files.
S100, burying points in a kernel layer of the subsystem so as to acquire the burying points when the subsystem is halted.
Specifically, the terminal equipment comprises user equipment such as a mobile phone and a watch for an android system, and the subsystem comprises a Wifi related module (wcnss subsytem), a communication related module (modem subsytem) and a Sensor related module (adsp subsytem).
For example, when the subsystem crash occurs, the big data embedded point reporting is performed, that is, when the subsystem crash occurs, the big data platform of the web end is reported.
And S200, receiving the attribute data packet, and selecting a corresponding dump file to store for analyzing the crash of the subsystem.
Specifically, the web platform, i.e. the big data platform of the web end, is pushed to the user equipment for an attribute value, and a switch of the dump file of the collection subsystem is opened.
By way of example, through the attribute and the attribute value set by the web platform, the web platform receives the set fields (attribute and attribute value) through the network, the terminal device receives the fields sent by the web terminal through the network, then parses the received fields, and selects the corresponding subsystem dump file by itself through the corresponding attribute and attribute value. The dump file refers to a memory file when each subsystem is abnormal when the subsystem crash problem is analyzed.
In the embodiment, the problem that the subsystem is abnormal and difficult to reproduce is solved, meanwhile, the user equipment does not need to send reproduction, the maintenance cost after sale is reduced, and the daily use of the user is not affected when the subsystem is abnormal.
Example five
The invention provides a terminal device which is applied to a method for analyzing the crash of a subsystem.
Specifically, the terminal device comprises user devices such as a mobile phone, a watch and a tablet which apply the android system.
The terminal device is used for setting the restarting level of each subsystem of the user version in the terminal device to be related so as to restart the subsystem which is dead.
The terminal equipment is used for transmitting the embedded point of the kernel layer to a framwork-layer interface function through android JNI communication, inserting the embedded point data into a laboratory database through the frawork-layer interface function, and sending the embedded point data to the webpage end in real time through the laboratory database.
The terminal equipment is used for analyzing and acquiring the attribute and the attribute value by utilizing the attribute data packet, selecting and storing a dump file of the subsystem according to the attribute and the attribute value, wherein the dump file comprises a memory file when the subsystem is halted.
The terminal equipment is used for receiving the attribute data packet, opening a dump file collection switch of the subsystem, and automatically collecting dump files of the subsystem based on the attribute data packet when the subsystem is halted again so as to analyze the halt of the subsystem.
Specifically, after the first occurrence of the crash of the subsystem, the web platform provides the attribute data packet, namely the attribute and the attribute value, to the terminal device, so that a collection switch of the elf file of the subsystem is opened, and when the crash of the subsystem of the android system in the terminal device occurs again, the dump file in the elf format can be directly collected.
In this embodiment, the dump file collection switch is opened by the attribute data packet generated in advance, so that the dump file can be automatically collected by the subsequent subsystem generated crash, so as to improve the efficiency of analyzing the cause of the crash of the subsystem.
And after receiving the attribute data packet, selecting a corresponding dump file for storage so as to analyze the halt of the subsystem, wherein the terminal equipment is used for compressing the dump file to generate a dump compressed file after collecting the dump file, storing the dump compressed file and deleting the dump file.
In this embodiment, by compressing the dump file, the saving space can be reduced, and the cache space is saved, so as to avoid the incomplete saving of the dump file caused by insufficient cache space.
Example five
The invention provides a system for analyzing the crash of a subsystem, which comprises terminal equipment and a webpage end.
And the webpage end is used for sending an attribute data packet for opening a dump file collection switch of the subsystem according to the buried point data so as to select a corresponding dump file to store for analyzing the crash of the subsystem.
In this embodiment, the attribute data packet for opening the dump file collection switch of the subsystem is sent through the web page end according to the buried point data sent by the terminal device, so that the terminal device opens the collection start of the dump of the subsystem, and the corresponding dump file is selected to be stored for analyzing that the subsystem is dead.
Illustratively, when subsystem crash occurs, the restart level of the user version is set to related.
Specifically, before the subsystem crash occurs, the default is to set the restart level of the user version to be related, and the debug version to be system.
The User version generally refers to a formally released software version provided for a User, and the debug generally refers to an informal software version used for development and debugging.
For example, after the restart level of the User version subsystem is set to be related, when crash occurs in the subsystem, the whole android system is not affected, the system is still normally operated, and the subsystem is restarted in the background, so that the whole system is not restarted. The performance on the user experience is that the user is completely unaware of the machine anomalies and is generally not affected by the use of other functions by the user during the subsystem restart. The purpose of setting relate the level is that the system crashes and only reboots some of the subsystems, not all of the subsystems.
And when the subsystem crash occurs, reporting the big data embedded point, namely reporting the big data platform of the web side when the subsystem crash occurs.
Specifically, when the subsystem crash occurs, the embedded point of the kernel layer of the android system is generally transmitted to the framwork-layer interface function of the android system through android JNI communication. The frawork-layer interface function reinserts the uploaded data into a laboratory database, and finally the laboratory sends the uploaded data to the web end in real time through a network (wifi or data traffic).
The web platform pushes an attribute value to the user device and opens a switch to collect subsystem dump files (elf files).
Specifically, through the attribute and the attribute value set by the web platform, the web platform receives the set fields (attribute and attribute value) through the network, the terminal equipment receives the fields sent by the web terminal through the network, then analyzes the received fields, and selects the corresponding subsystem dump file by the user through the corresponding attribute and attribute value. The dump file refers to a memory file when each subsystem needed to analyze the crash problem of the subsystem is abnormal, and the file format is an elf file.
When the machine generates the subsystem crash again, dump files of the subsystem are automatically collected, and in order to reduce the occupied space of a user, the field files are compressed and then stored.
The compression mechanism is that after the dump file is collected, the dump file is compressed and the original file is deleted, and only the compressed file is reserved.
The developer pulls the dump file of the subsystem through the network by using the web end, and then analyzes the dump file.
Because the report device list of the generation subsystem is arranged on the web platform every day, when the device generates the subsystem crash again, the dump file can be pulled through the network by the hidden name of the web platform. Because the method mainly aims at the user equipment, the network is generally used for pulling, and the method can be used for obtaining the local adb pull file.
In the embodiment, the invention can analyze subsystem crash equipment which is not easy to reproduce in the market, solves the problems of the prior analysis, can meet the key dump log required by a developer for analyzing crash, and can excessively consume the data flow of a user.
The default subsystem restart level of the general equipment is system, KERNEL PANIC is caused after the subsystem generates crash, the whole machine is pulled and the performance of the user equipment is that the whole machine is restarted. Besides passing through ramdump of DDR, the analysis can be performed through the elf file of a specific subsystem, and when crash occurs to the subsystem, the restarting level of each subsystem in the android system is set to be related, so that system breakdown cannot be caused when the subsystem is abnormal, and the corresponding subsystem can be restarted in the background. After the restart level is set to be related, the electronic file of the corresponding subsystem is generated when crash occurs. The reasons for subsystem crash can also be analyzed by these elf files.
In the embodiment, the invention can analyze subsystem crash equipment which is not easy to reproduce in the market, solves the problems of the prior analysis, can meet the key dump log required by a developer for analyzing crash, and can excessively consume the data flow of a user. The default subsystem restart level of the general equipment is system, KERNEL PANIC is caused after the subsystem generates crash, the whole machine is pulled and the performance of the user equipment is that the whole machine is restarted. Besides through ramdump of DDR, the analysis can be performed through the elf file of the specific subsystem, and when crash occurs in the subsystem, the restarting level of the subsystem is set to be related, so that system breakdown cannot be caused when the subsystem is abnormal, and the corresponding subsystem can be restarted in the background. After the restart level is set to be related, the electronic file of the corresponding subsystem is generated when crash occurs. The reasons for subsystem crash can also be analyzed by these elf files.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The system embodiments described above are exemplary only, and exemplary, the division of the modules or units is merely a logical function division, and there may be additional divisions in actual implementation, exemplary, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
It should be noted that the above embodiments can be freely combined as needed. The foregoing is merely a preferred embodiment of the present invention and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present invention, which are intended to be comprehended within the scope of the present invention.