CN110727577B - Debugging method, system and medium for probability reproduction problem in embedded system software - Google Patents
Debugging method, system and medium for probability reproduction problem in embedded system software Download PDFInfo
- Publication number
- CN110727577B CN110727577B CN201910809074.2A CN201910809074A CN110727577B CN 110727577 B CN110727577 B CN 110727577B CN 201910809074 A CN201910809074 A CN 201910809074A CN 110727577 B CN110727577 B CN 110727577B
- Authority
- CN
- China
- Prior art keywords
- observation point
- observation
- data
- points
- range
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3628—Software debugging of optimised code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a debugging method, a system and a medium for probability reproduction problems in embedded system software, comprising the following steps: observation point insertion: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data; and (3) a waiting problem reproduction step: re-executing the software and waiting for the problem to recur; observation point increasing step: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, adding a new observation point, and entering a problem range reduction step to continue to be executed; otherwise, the viewpoint data of the next event position is analyzed. The invention can debug the code to be debugged in a non-invasive way. The integrity of the code to be debugged is not compromised.
Description
Technical Field
The invention relates to the technical field of debugging of embedded software, in particular to a debugging method, a system and a medium for probability reproduction problems in embedded system software. And more particularly to debugging unstable reproduction or random problems.
Background
With development and maturity of embedded technology, application fields of embedded software are becoming wider and wider. The development of embedded software is basically dependent on the embedded operating system. Application code written by application software developers needs to run on top of a particular embedded operating system. In the embedded software development process, program debugging takes up most of the time of the developer. Especially in the face of complex application scenarios, it is difficult to locate the problem without assistance from operating system developers. The scene frequently encountered in the software debugging process is as follows:
1. the probability is repeated, and as the problem sites can appear at different places at different moments, the conventional debugging means are difficult to locate, and the commonalities and laws of the different problem sites are difficult to find.
2. If the program to be debugged starts the compiler optimization option, the conventional debugging means is very difficult, and the breakpoint is difficult to add or even cannot be subjected to single-step debugging.
3. The conventional debugging method can add codes into the codes to be debugged, even pile the codes, consume a great deal of CPU time and influence the integrity of the programs to be debugged.
Related search result 1:
application (patent) number 20080224680. X name: a software debugging system and debugging method
The system comprises a PC end and an embedded system end which are connected, and is used for debugging software to be debugged, which runs on the PC end and the embedded system end at the same time; the software to be debugged is divided into N function sets, and each function set comprises one or more functions; the PC end comprises a debugging control unit and a debugging level judging device; the embedded system end comprises an embedded debugging interface; the debugging control unit sets a system operation level set and operation level values corresponding to the function sets; after intercepting the call of the function in the ith function set to the function in the jth function set in the debugging process, the debugging level judging device judges whether the operation level value of the jth function set is contained in the system operation level set, and if so, the called function operated on the PC side is called; otherwise, sending a debugging command to the embedded debugging interface, and calling the same function running on the embedded system by the embedded debugging interface
The technical points are compared:
1. a complex debugging environment comprising a debugging control unit and a debugging level judging device is required to be built at the pc end, the debugging process can influence the code executing process, and the integrity of the code to be debugged is damaged.
2. The method can only start from the function level, the debugging granularity is relatively coarse, the selected function can only be executed in the pc-type environment, and the debugging freedom degree is not high. And if complex scenarios related to timing are encountered, such as interrupts and signal intervention, debugging is difficult.
Related search result 2:
application (patent) number 201410010606.3 name, a software debugging device and method with multiple break points
The invention discloses a software debugging device and method with multiple breakpoints, wherein the software debugging device comprises: drivers, microprocessors, instruction memory, and microcode Integrated Development Environments (IDEs); the software debugging device acquires breakpoint information by setting a breakpoint in a software program, replaces an instruction at the breakpoint with the breakpoint instruction, reports an interrupt and freezes a pipeline when the breakpoint instruction is executed, replaces the breakpoint instruction with a real instruction according to a command issued by an IDE, thaws the pipeline, fetches the real instruction at the breakpoint, and replaces the real instruction at the breakpoint with the breakpoint instruction again in the executing gap of the breakpoint instruction to realize multi-breakpoint software debugging
The technical points are compared:
the method relies on the successful setting and triggering of breakpoints. When encountering the compiler optimization option, the program to be debugged can be subjected to optimization adjustment to carry out instruction rearrangement, and the breakpoint position can be disturbed or even the breakpoint cannot be added at the correct position, so that debugging cannot be carried out.
Related search result 3:
application (patent) number 201410353773.8 name, software debugging method and device
The application discloses a software debugging method and device, wherein the method comprises the following steps: receiving a trigger event, judging the type of the trigger event, inquiring an operation object corresponding to the trigger event, and marking the operation object in a current system view window; and executing the business logic corresponding to the trigger event according to the type of the trigger event. According to the invention, the operation object corresponding to the triggering event is marked in the system view window, so that a programmer can visually see the operation object triggered currently, and the programmer can quickly locate the cause of the problem, thereby finding the specific position of the bug, improving the software debugging efficiency and avoiding the time consumption caused by positioning the bug according to experience by the programmer.
The technical points are compared:
the method needs to rely on a hardware debugging device, and has special requirements on debugging resources.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a debugging method, a system and a medium for probability reproduction problem in embedded system software.
The invention provides a debugging method for probability reproduction problems in embedded system software, which comprises the following steps:
observation point insertion: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data;
and (3) a waiting problem reproduction step: re-executing the software and waiting for the problem to recur;
observation point increasing step: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, adding a new observation point, and entering a problem range reduction step to continue to be executed; otherwise, analyzing the observation point data of the position of the next event;
problem range reduction step: judging whether the problem range can be narrowed according to the data collected by the observation point: if the problem range cannot be narrowed, returning to the observation point increasing step to continue to execute; if the problem range can be narrowed, two observation points after narrowing the range are obtained, and the repeated observation step is carried out continuously;
and (3) repeating the observation steps: re-executing the software to see if the problem is stably reproduced in the two obtained reduced-range observation point ranges: if not, combining the newly added viewpoint data, returning to the viewpoint adding step to continue execution; if the problem can be observed to be stably reproduced, entering an error locking step;
error locking step: according to the problem that the data analysis of the observation points can be stably repeated, finding out the scene with errors, and if the scene with errors cannot be found out, returning to the observation point adding step to continue execution.
Specifically, the viewpoint inserting step:
the event includes: the moment when the task switching of the operating system occurs, the moment when software or hardware interrupt is triggered and the moment when the interrupt returns;
the data collected by the observation point comprises: the state of the current CPU register and the value of part of key memory addresses at the moment of occurrence of the event;
the insertion observation point: adding an observation point by setting a watchpoint through a CPU debugging function;
and storing the data acquired by the observation point into an idle memory or a flash memory area.
Specifically, the observation point increasing step:
reading the observation point data, obtaining the sequence and execution sequence triggered by the operating system event, positioning the event nearest to the moment of occurrence of the problem, obtaining the observation point of the event, analyzing, and judging whether execution errors occur or not: if yes, adding a new observation point before the observation point of the event, and entering a problem range reduction step to continue execution; otherwise, continuing to analyze the viewpoint data of the next event position.
The execution error includes: program execution branch errors, data flow errors, and global variable errors.
Specifically, the problem area narrowing step:
judging whether the problem range can be narrowed according to the data collected by the observation point:
if the two continuous observation point data are normal, the latter is abnormal, namely, the code between the two continuous observation points is indicated to have a problem, therefore, if the newly added observation point data and the original observation point data have a phenomenon of normal one abnormality, the problem range can be considered to be narrowed, according to the data collected by the observation points, the data of the observation points are analyzed from which observation point, the problem is generated, the problem range is narrowed to be in the two observation points closest to the problem generating point, and the two observation points after the narrowing range are obtained.
If the two continuous observation point data are not existed, the former is normal, and the latter is abnormal, the program execution sequence is not triggered, namely the range cannot be narrowed, and the observation point increasing step is returned to continue to be executed.
Specifically, the recurrence observation step:
re-executing the software, analyzing an operating system event triggering sequence and a software execution sequence of two execution processes before and after the moment of occurrence of the problem, if the execution sequence is consistent with the event triggering sequence, indicating that the two execution processes stably reproduce the problem, and entering an error locking step to continue execution; if the observation point data are inconsistent, the problem is not stably reproduced, and the observation point adding step is returned to be continuously executed by combining the newly added observation point data.
The invention provides a debugging system for probability reproduction problems in embedded system software, which comprises
The observation point insertion module: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data;
and a waiting problem reproduction module: re-executing the software and waiting for the problem to recur;
the observation point adding module: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, a new observation point is added, and a problem range reduction module is called; otherwise, analyzing the observation point data of the position of the next event;
problem area reduction module: judging whether the problem range can be narrowed according to the data collected by the observation point: if the problem range cannot be narrowed, calling an observation point adding module; if the problem range can be reduced, two observation points after the problem range is reduced are obtained, and a reproduction observation module is called;
and (3) a reproduction observation module: re-executing the software to see if the problem is stably reproduced in the two obtained reduced-range observation point ranges: if not, calling the viewpoint adding module to continue execution by combining the newly added viewpoint data; if the problem can be observed to be stably reproduced, calling an error locking module;
error locking module: according to the problem that the analysis of the observation points can be stably repeated, finding out the scene with errors, and if the scene with errors cannot be found out, calling an observation point adding module.
Specifically, the viewpoint insertion module:
the event includes: the moment when the task switching of the operating system occurs, the moment when software or hardware interrupt is triggered and the moment when the interrupt returns;
the data collected by the observation point comprises: the state of the current CPU register and the value of part of key memory addresses at the moment of occurrence of the event;
the insertion observation point: adding an observation point by setting a watchpoint through a CPU debugging function;
and storing the data acquired by the observation point into an idle memory or a flash memory area.
Specifically, the viewpoint adding module:
reading the observation point data, obtaining the sequence and execution sequence triggered by the operating system event, positioning the event nearest to the moment of occurrence of the problem, obtaining the observation point of the event, analyzing, and judging whether execution errors occur or not: if yes, adding a new observation point before the observation point of the event, and calling a problem range reduction module; otherwise, continuing to analyze the viewpoint data of the next event position.
The execution error includes: program execution branch errors, data flow errors, and global variable errors.
Specifically, the problem area narrowing module:
judging whether the problem range can be narrowed according to the data collected by the observation point:
if the two continuous observation point data are normal, the latter is abnormal, namely, the code between the two continuous observation points is indicated to have a problem, therefore, if the newly added observation point data and the original observation point data have a phenomenon of normal one abnormality, the problem range can be considered to be narrowed, according to the data collected by the observation points, the data of the observation points are analyzed from which observation point, the problem is generated, the problem range is narrowed to be in the two observation points closest to the problem generating point, and the two observation points after the narrowing range are obtained.
If the former one is normal and the latter one is abnormal, the program execution sequence is proved to have no triggering problem, namely the scope cannot be narrowed, and the viewpoint adding module is called;
the reproduction observation module:
re-executing software, analyzing an operating system event triggering sequence and a software execution sequence of two execution processes before and after the moment of occurrence of a problem, and calling an error locking module if the execution sequence and the event triggering sequence are consistent, wherein the two execution processes are stable and the problem is repeated; if the observation point data are inconsistent, the problem is not stably reproduced, and the observation point adding module is called in combination with the newly added observation point data.
The invention provides a computer readable storage medium storing a computer program, which is characterized in that the computer program when executed by a processor realizes the steps of the debugging method for probability recurrence of problems in any one of the above embedded system software.
Compared with the prior art, the invention has the following beneficial effects:
1. the invention can debug the code to be debugged in a non-invasive way. The integrity of the code to be debugged is not compromised.
2. Aiming at the probability recurrence problem, the conventional debugging means are difficult to locate because the problem site can appear at different positions at different moments, and the commonality and regularity in different problem sites can be analyzed by using the method of the invention, so that the problem range is reduced until the problem can be stably reappeared in a section of cells, and the problem is found.
3. Aiming at the scene of starting compiler optimization, the code execution sequence can be rearranged by the compiler, so that the conventional debugging breakpoint is invalid, and even single-step debugging cannot be performed. The observation point is added through the watchpoint function in the CPU, so that the observation point is not influenced by compiler optimization, and the problem can be rapidly positioned.
4. For the problem that the problem cannot be stably reproduced, the range can be rapidly reduced so that the problem can be stably reproduced to locate the problem site.
Drawings
Other features, objects and advantages of the present invention will become more apparent upon reading of the detailed description of non-limiting embodiments, given with reference to the accompanying drawings in which:
fig. 1 is a schematic flow chart of a debugging method provided by the invention.
Fig. 2 is a schematic diagram of a partial execution sequence of a program to be debugged according to a preferred embodiment of the present invention.
Fig. 3 is a schematic diagram of a partial execution sequence of a program to be debugged according to a preferred embodiment of the present invention.
Detailed Description
The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the present invention, but are not intended to limit the invention in any way. It should be noted that variations and modifications could be made by those skilled in the art without departing from the inventive concept. These are all within the scope of the present invention.
The invention provides a debugging method for probability reproduction problems in embedded system software, which comprises the following steps:
observation point insertion: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data;
and (3) a waiting problem reproduction step: re-executing the software and waiting for the problem to recur;
observation point increasing step: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, adding a new observation point, and entering a problem range reduction step to continue to be executed; otherwise, analyzing the observation point data of the position of the next event;
problem range reduction step: judging whether the problem range can be narrowed according to the data collected by the observation point: if the problem range cannot be narrowed, returning to the observation point increasing step to continue to execute; if the problem range can be narrowed, two observation points after narrowing the range are obtained, and the repeated observation step is carried out continuously;
and (3) repeating the observation steps: re-executing the software to see if the problem is stably reproduced in the two obtained reduced-range observation point ranges: if not, combining the newly added viewpoint data, returning to the viewpoint adding step to continue execution; if the problem can be observed to be stably reproduced, entering an error locking step;
error locking step: according to the problem that the data analysis of the observation points can be stably repeated, finding out the scene with errors, and if the scene with errors cannot be found out, returning to the observation point adding step to continue execution.
Preferably, the viewpoint inserting step:
the event includes: the moment when the task switching of the operating system occurs, the moment when software or hardware interrupt is triggered and the moment when the interrupt returns;
the data collected by the observation point comprises: the state of the current CPU register and the value of part of key memory addresses at the moment of occurrence of the event;
the insertion observation point: adding an observation point by setting a watchpoint through a CPU debugging function;
and storing the data acquired by the observation point into an idle memory or a flash memory area.
Preferably, the observation point increasing step:
reading the observation point data, obtaining the sequence and execution sequence triggered by the operating system event, positioning the event nearest to the moment of occurrence of the problem, obtaining the observation point of the event, analyzing, and judging whether execution errors occur or not: if yes, adding a new observation point before the observation point of the event, and entering a problem range reduction step to continue execution; otherwise, continuing to analyze the viewpoint data of the next event position.
The execution error includes: program execution branch errors, data flow errors, and global variable errors.
Preferably, the problem area narrowing step:
judging whether the problem range can be narrowed according to the data collected by the observation point:
if the two continuous observation point data are normal, the latter is abnormal, namely, the code between the two continuous observation points is indicated to have a problem, therefore, if the newly added observation point data and the original observation point data have a phenomenon of normal one abnormality, the problem range can be considered to be narrowed, according to the data collected by the observation points, the data of the observation points are analyzed from which observation point, the problem is generated, the problem range is narrowed to be in the two observation points closest to the problem generating point, and the two observation points after the narrowing range are obtained.
If the two continuous observation point data are not existed, the former is normal, and the latter is abnormal, the program execution sequence is not triggered, namely the range cannot be narrowed, and the observation point increasing step is returned to continue to be executed.
Preferably, the reproduction observing step:
re-executing the software, analyzing an operating system event triggering sequence and a software execution sequence of two execution processes before and after the moment of occurrence of the problem, if the execution sequence is consistent with the event triggering sequence, indicating that the two execution processes stably reproduce the problem, and entering an error locking step to continue execution; if the observation point data are inconsistent, the problem is not stably reproduced, and the observation point adding step is returned to be continuously executed by combining the newly added observation point data.
The debugging system for the probability recurrence problem in the embedded system software can be realized through the step flow of the debugging method for the probability recurrence problem in the embedded system software. Those skilled in the art can understand the debugging method of the probability replication problem in the embedded system software as a preferred example of the debugging system of the probability replication problem in the embedded system software.
The invention provides a debugging system for probability reproduction problems in embedded system software, which comprises
The observation point insertion module: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data;
and a waiting problem reproduction module: re-executing the software and waiting for the problem to recur;
the observation point adding module: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, a new observation point is added, and a problem range reduction module is called; otherwise, analyzing the observation point data of the position of the next event;
problem area reduction module: judging whether the problem range can be narrowed according to the data collected by the observation point: if the problem range cannot be narrowed, calling an observation point adding module; if the problem range can be reduced, two observation points after the problem range is reduced are obtained, and a reproduction observation module is called;
and (3) a reproduction observation module: re-executing the software to see if the problem is stably reproduced in the two obtained reduced-range observation point ranges: if not, calling the viewpoint adding module to continue execution by combining the newly added viewpoint data; if the problem can be observed to be stably reproduced, calling an error locking module;
error locking module: according to the problem that the analysis of the observation points can be stably repeated, finding out the scene with errors, and if the scene with errors cannot be found out, calling an observation point adding module.
Preferably, the viewpoint insertion module:
the event includes: the moment when the task switching of the operating system occurs, the moment when software or hardware interrupt is triggered and the moment when the interrupt returns;
the data collected by the observation point comprises: the state of the current CPU register and the value of part of key memory addresses at the moment of occurrence of the event;
the insertion observation point: adding an observation point by setting a watchpoint through a CPU debugging function;
and storing the data acquired by the observation point into an idle memory or a flash memory area.
Preferably, the viewpoint adding module:
reading the observation point data, obtaining the sequence and execution sequence triggered by the operating system event, positioning the event nearest to the moment of occurrence of the problem, obtaining the observation point of the event, analyzing, and judging whether execution errors occur or not: if yes, adding a new observation point before the observation point of the event, and calling a problem range reduction module; otherwise, continuing to analyze the viewpoint data of the next event position.
The execution error includes: program execution branch errors, data flow errors, and global variable errors.
Preferably, the problem area narrowing module:
judging whether the problem range can be narrowed according to the data collected by the observation point:
if the two continuous observation point data are normal, the latter is abnormal, namely, the code between the two continuous observation points is indicated to have a problem, therefore, if the newly added observation point data and the original observation point data have a phenomenon of normal one abnormality, the problem range can be considered to be narrowed, according to the data collected by the observation points, the data of the observation points are analyzed from which observation point, the problem is generated, the problem range is narrowed to be in the two observation points closest to the problem generating point, and the two observation points after the narrowing range are obtained.
If the former one is normal and the latter one is abnormal, the program execution sequence is proved to have no triggering problem, namely the scope cannot be narrowed, and the viewpoint adding module is called;
the reproduction observation module:
re-executing software, analyzing an operating system event triggering sequence and a software execution sequence of two execution processes before and after the moment of occurrence of a problem, and calling an error locking module if the execution sequence and the event triggering sequence are consistent, wherein the two execution processes are stable and the problem is repeated; if the observation point data are inconsistent, the problem is not stably reproduced, and the observation point adding module is called in combination with the newly added observation point data.
The invention provides a computer readable storage medium storing a computer program, which is characterized in that the computer program when executed by a processor realizes the steps of the debugging method for probability recurrence of problems in any one of the above embedded system software.
The present invention will be described more specifically by way of preferred examples.
Preferred example 1:
as shown in fig. 1, a method for debugging a probability reproduction problem in embedded system software includes:
step 1: observation points are inserted at each event occurrence point and end point within the operating system.
Step 2: re-executing the software and waiting for the problem to recur.
Step 3: the viewpoint data is analyzed and the viewpoint is increased.
Step 4: if the problem cannot be narrowed, the process returns to step 3.
Typically, the location of a software bug to be debugged is within a certain line of code or a certain piece of code. All the operating conditions are normal before the line or piece of code is executed. An exception occurs in the running state after execution, and is typically represented by a program execution branch error, a data flow error, a global variable error, and the like.
The establishment of the observation point is the state of a certain point in the running process of the acquisition program. For example, some two consecutive collection points are normal in data, i.e., indicating that no bug has occurred in the code between the two points. If the data of a certain two continuous acquisition points are normal before, the data of the later data are abnormal, the problem of the code between the two points is indicated.
During preliminary debugging, the number of code lines between the two acquisition points is larger, so that the problem code position can be positioned probably. After the preliminary positioning is completed, accurate positioning to a certain line of codes is required. An acquisition point is added between these two points. If the above-mentioned phenomenon of normal and abnormal can still appear at the newly added acquisition point and the old acquisition point, the problem range is reduced.
Because the probability recurrence problem is solved, if the data of one acquisition point is normal and the data of the later acquisition point is abnormal, the problem that the program execution sequence is not triggered at the time is indicated, namely the range cannot be narrowed.
Step 5: the software is re-executed to see if the problem is stably reproduced in the range of certain two observation points. If not, the problem is analyzed by combining the newly added viewpoint data, and the step 3 is returned. If a stable recurrence can be observed, step 6 is entered.
Step 6: the problem of stable reproduction can be solved by analyzing the observation point data, and the observation point can be added again for observation if necessary. Eventually, the site where the error occurs can be found.
In step 1, the event is defined as the moment when the task switch of the operating system occurs, the moment when the software/hardware interrupt is triggered, and the moment when the interrupt returns. The information collected by the observation point includes the state of the current CPU registers (general purpose registers and special registers) and the values of part of the critical memory addresses at the time of the event. The watchpoint is set by the CPU debug function to add the viewpoint. The collected data is stored to an empty memory or flash memory area.
In step 2, the problem is the problem that this debugging needs to solve. Such as a false variable assignment, or memory overflow due to an algorithm error, or the lack of protection of common resources in a multi-threaded environment. After the software has the error/bug, the running state of the software is abnormal, and the abnormal state is detected by the verification function of the software and is informed to a user by suspending an operating system, outputting error information and the like. Waiting for the problem to recur here waits for these anomalies to occur.
In step 3, the viewpoint data is analyzed as follows
Reading the observation point data in the step 1, obtaining the sequence triggered by the events of the operating system and the approximate execution sequence, positioning the event nearest to the moment of occurrence of the problem, analyzing the observation point data by combining the codes, and analyzing the sequence and the observation point data of the sequence before and after two times due to the probability of the problem of reproduction. Analyzing the sequence of two times before and after the analysis refers to analyzing the trigger sequence of the events of the operating system and the execution sequence of software in the two execution processes. If the execution sequence and the event triggering sequence are consistent, the problem is stably reproduced in the two execution steps, and the analysis of the observation point data means the analysis of whether program execution branch errors, data flow errors, global variable errors and the like occur. If the viewpoint data has been erroneous, a new viewpoint may be added before the point. If no error occurs, the observation point data of the next event position is continuously analyzed.
In step 4, the narrowing the problem range means: for example, in a certain debugging, the abnormal phenomenon is that the func () function returns a value error, so that observation points can be added before and after func_b () and func_c () of 3 sub functions func_a (), respectively, after 6 observation point information is obtained, from which observation point is analyzed, the function must go to an error branch to obtain an error return value.
Assuming that in viewpoint information after the func_b () function, the value of a certain key global variable is erroneous, and that the viewpoint before func_b () is not erroneous, the problem scope can be narrowed down to within the func_b () function.
And repeating the process, and finally locating the code line with the problem. The whole iterative process is the way to narrow down the problem.
In step 5, assume that 6 observation points are a, B, C, D, E, F, respectively. Since a problem occurs in func_b (), the three viewpoint information of a, B, C are normal and the three viewpoint information of D, E, F are wrong. The problem can be said to recur between the two points of view C, D. Two observation points nearest to the problem occurrence point, namely, two points C and D in the above example, are taken. Thus, the debugging progress can be accelerated to the maximum extent. Therefore, the debugging method only focuses on the occurrence time of the problem, and two observation points are arranged in front of and behind the nearest one.
Preferred example 2:
1. under the embedded environment, observation points are added before and after task switching of the kernel of the operating system and before and after interrupt response.
2. Executing the program to be debugged, and waiting for the problem to be repeated. After the problem is repeated, reading the data of the observation point to obtain a partial execution sequence of the program to be debugged, which is shown in fig. 2.
3. Analyzing the four observation points of the ABCD can find that the data of the two observation points of the AB are correct, the data at the C position cannot be judged, and the data at the D position is wrong, so that the operation in the task C is wrong. Therefore, an observation point is added in the subtask of the task B, and the program to be debugged is re-executed.
4. After the problem is repeated again, reading the data of the observation point, and finding that the problem is changed at the moment, and obtaining a part of execution sequence of the program to be debugged is shown in fig. 3.
5. And analyzing the observation points A to F again, and finding that the data of the five observation points ABCDE are correct, wherein the data of the observation points F are wrong. In combination with the last step of the trial results, the problem can be localized within the interrupt service routine. So that a viewpoint is added within the interrupt service routine.
6. And repeating the two steps, stably reproducing the final problem, positioning the problem to a certain code in the interrupt service routine, and ending the whole debugging process.
Those skilled in the art will appreciate that the systems, apparatus, and their respective modules provided herein may be implemented entirely by logic programming of method steps such that the systems, apparatus, and their respective modules are implemented as logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc., in addition to the systems, apparatus, and their respective modules being implemented as pure computer readable program code. Therefore, the system, the apparatus, and the respective modules thereof provided by the present invention may be regarded as one hardware component, and the modules included therein for implementing various programs may also be regarded as structures within the hardware component; modules for implementing various functions may also be regarded as being either software programs for implementing the methods or structures within hardware components.
The foregoing describes specific embodiments of the present invention. It is to be understood that the invention is not limited to the particular embodiments described above, and that various changes or modifications may be made by those skilled in the art within the scope of the appended claims without affecting the spirit of the invention. The embodiments of the present application and features in the embodiments may be combined with each other arbitrarily without conflict.
Claims (8)
1. The debugging method for the probability reproduction problem in the embedded system software is characterized by comprising the following steps of:
observation point insertion: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data;
and (3) a waiting problem reproduction step: re-executing the software and waiting for the problem to recur;
observation point increasing step: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, adding a new observation point, and entering a problem range reduction step to continue to be executed; otherwise, analyzing the observation point data of the position of the next event;
problem range reduction step: judging whether the problem range can be narrowed according to the data collected by the observation point: if the problem range cannot be narrowed, returning to the observation point increasing step to continue to execute; if the problem range can be narrowed, two observation points after narrowing the range are obtained, and the repeated observation step is carried out continuously;
and (3) repeating the observation steps: re-executing the software to see if the problem is stably reproduced in the two obtained reduced-range observation point ranges: if not, combining the newly added viewpoint data, returning to the viewpoint adding step to continue execution; if the problem can be observed to be stably reproduced, entering an error locking step;
error locking step: according to the problem that the data analysis of the observation points can be stably repeated, finding out the site with errors, and if the site with errors cannot be found out, returning to the observation point adding step to continue to execute;
the observation point inserting step:
the event includes: the moment when the task switching of the operating system occurs, the moment when software or hardware interrupt is triggered and the moment when the interrupt returns;
the data collected by the observation point comprises: the state of the current CPU register and the value of part of key memory addresses at the moment of occurrence of the event;
the insertion observation point: adding an observation point by setting a watchpoint through a CPU debugging function;
and storing the data acquired by the observation point into an idle memory or a flash memory area.
2. The debugging method of probability reproduction problem in embedded system software of claim 1, wherein the observation point increasing step:
reading the observation point data, obtaining the sequence and execution sequence triggered by the operating system event, positioning the event nearest to the moment of occurrence of the problem, obtaining the observation point of the event, analyzing, and judging whether execution errors occur or not: if yes, adding a new observation point before the observation point of the event, and entering a problem range reduction step to continue execution; otherwise, continuing to analyze the observation point data of the next event position;
the execution error includes: program execution branch errors, data flow errors, and global variable errors.
3. The debugging method of probability reproduction problem in embedded system software according to claim 2, wherein the problem range reduction step:
judging whether the problem range can be narrowed according to the data collected by the observation point:
if the two continuous observation point data are normal, the latter is abnormal, namely, the code between the two continuous observation points is indicated to have a problem, therefore, if the newly added observation point data and the original observation point data have a normal phenomenon and an abnormal phenomenon, the problem range can be considered to be narrowed, according to the data collected by the observation points, the data of the observation points are analyzed from which observation point, the problem is generated, the problem range is narrowed to be in the two observation points closest to the problem occurrence point, and the two observation points after the narrowing range are obtained;
if the two continuous observation point data are not existed, the former is normal, and the latter is abnormal, the program execution sequence is not triggered, namely the range cannot be narrowed, and the observation point increasing step is returned to continue to be executed.
4. A method for debugging a probabilistic reproduction problem in embedded system software as claimed in claim 3, wherein the reproduction observing step:
re-executing the software, analyzing an operating system event triggering sequence and a software execution sequence of two execution processes before and after the moment of occurrence of the problem, if the execution sequence is consistent with the event triggering sequence, indicating that the two execution processes stably reproduce the problem, and entering an error locking step to continue execution; if the observation point data are inconsistent, the problem is not stably reproduced, and the observation point adding step is returned to be continuously executed by combining the newly added observation point data.
5. A debugging system for probability reproduction problem in embedded system software is characterized by comprising
The observation point insertion module: inserting observation points into the occurrence points and the end points of all events in the operating system, and enabling the observation points to acquire data;
and a waiting problem reproduction module: re-executing the software and waiting for the problem to recur;
the observation point adding module: analyzing the data acquired by the observation points to obtain an analysis result, and judging whether the observation points are to be added or not according to the analysis result: if yes, a new observation point is added, and a problem range reduction module is called; otherwise, analyzing the observation point data of the position of the next event;
problem area reduction module: judging whether the problem range can be narrowed according to the data collected by the observation point: if the problem range cannot be narrowed, calling an observation point adding module; if the problem range can be reduced, two observation points after the problem range is reduced are obtained, and a reproduction observation module is called;
and (3) a reproduction observation module: re-executing the software to see if the problem is stably reproduced in the two obtained reduced-range observation point ranges: if not, calling the viewpoint adding module to continue execution by combining the newly added viewpoint data; if the problem can be observed to be stably reproduced, calling an error locking module;
error locking module: according to the problem that the analysis of the viewpoint data can be repeated stably, finding out the scene with errors, and if the scene with errors cannot be found out, calling a viewpoint adding module;
the viewpoint insertion module:
the event includes: the moment when the task switching of the operating system occurs, the moment when software or hardware interrupt is triggered and the moment when the interrupt returns;
the data collected by the observation point comprises: the state of the current CPU register and the value of part of key memory addresses at the moment of occurrence of the event;
the insertion observation point: adding an observation point by setting a watchpoint through a CPU debugging function;
and storing the data acquired by the observation point into an idle memory or a flash memory area.
6. The debugging system of probabilistic reproduction problem in embedded system software of claim 5, wherein the observation point adding module:
reading the observation point data, obtaining the sequence and execution sequence triggered by the operating system event, positioning the event nearest to the moment of occurrence of the problem, obtaining the observation point of the event, analyzing, and judging whether execution errors occur or not: if yes, adding a new observation point before the observation point of the event, and calling a problem range reduction module; otherwise, continuing to analyze the observation point data of the next event position;
the execution error includes: program execution branch errors, data flow errors, and global variable errors.
7. The debugging system of probabilistic reproduction problem in embedded system software of claim 6, wherein the problem scope reduction module:
judging whether the problem range can be narrowed according to the data collected by the observation point:
if the two continuous observation point data are normal, the latter is abnormal, namely, the code between the two continuous observation points is indicated to have a problem, therefore, if the newly added observation point data and the original observation point data have a normal phenomenon and an abnormal phenomenon, the problem range can be considered to be narrowed, according to the data collected by the observation points, the data of the observation points are analyzed from which observation point, the problem is generated, the problem range is narrowed to be in the two observation points closest to the problem occurrence point, and the two observation points after the narrowing range are obtained;
if the former one is normal and the latter one is abnormal, the program execution sequence is proved to have no triggering problem, namely the scope cannot be narrowed, and the viewpoint adding module is called;
the reproduction observation module:
re-executing software, analyzing an operating system event triggering sequence and a software execution sequence of two execution processes before and after the moment of occurrence of a problem, and calling an error locking module if the execution sequence and the event triggering sequence are consistent, wherein the two execution processes are stable and the problem is repeated; if the observation point data are inconsistent, the problem is not stably reproduced, and the observation point adding module is called in combination with the newly added observation point data.
8. A computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for debugging a probabilistic reproduction problem in embedded system software as claimed in any one of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910809074.2A CN110727577B (en) | 2019-08-29 | 2019-08-29 | Debugging method, system and medium for probability reproduction problem in embedded system software |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910809074.2A CN110727577B (en) | 2019-08-29 | 2019-08-29 | Debugging method, system and medium for probability reproduction problem in embedded system software |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110727577A CN110727577A (en) | 2020-01-24 |
| CN110727577B true CN110727577B (en) | 2023-06-09 |
Family
ID=69217793
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910809074.2A Active CN110727577B (en) | 2019-08-29 | 2019-08-29 | Debugging method, system and medium for probability reproduction problem in embedded system software |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110727577B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112035351A (en) * | 2020-08-27 | 2020-12-04 | 优学汇信息科技(广东)有限公司 | Computer software technology development debugging system and debugging method |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000181746A (en) * | 1998-12-18 | 2000-06-30 | Toshiba Corp | Processor with debug support and debug function execution control method |
| CN1912849A (en) * | 2006-09-01 | 2007-02-14 | 上海大学 | Chip dynamic tracing method of microprocessor |
| CN101122880A (en) * | 2007-09-17 | 2008-02-13 | 福建星网锐捷网络有限公司 | Embedded type system of embed type debugging device and embedded type system debugging method |
| CN101135990A (en) * | 2007-06-19 | 2008-03-05 | 中兴通讯股份有限公司 | System fault positioning method |
| CN103678112A (en) * | 2012-08-29 | 2014-03-26 | 飞思卡尔半导体公司 | Data processor device for handling a watchpoint and method thereof |
| CN104239201A (en) * | 2013-06-20 | 2014-12-24 | 上海博达数据通信有限公司 | Memory read-write monitoring method in flexible single-step system |
| CN104252402A (en) * | 2014-09-05 | 2014-12-31 | 深圳创维数字技术有限公司 | Program debugging method and device |
| CN106776208A (en) * | 2016-12-02 | 2017-05-31 | 中国航天系统科学与工程研究院 | Fault Locating Method during a kind of running software |
| CN108829591A (en) * | 2018-05-31 | 2018-11-16 | 北京理工大学 | A kind of synergic debugging system and method based on Web |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101060181B1 (en) * | 2009-08-03 | 2011-08-29 | 강원대학교산학협력단 | Web-based software debugging device and its method for remote debugging |
-
2019
- 2019-08-29 CN CN201910809074.2A patent/CN110727577B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000181746A (en) * | 1998-12-18 | 2000-06-30 | Toshiba Corp | Processor with debug support and debug function execution control method |
| CN1912849A (en) * | 2006-09-01 | 2007-02-14 | 上海大学 | Chip dynamic tracing method of microprocessor |
| CN101135990A (en) * | 2007-06-19 | 2008-03-05 | 中兴通讯股份有限公司 | System fault positioning method |
| CN101122880A (en) * | 2007-09-17 | 2008-02-13 | 福建星网锐捷网络有限公司 | Embedded type system of embed type debugging device and embedded type system debugging method |
| CN103678112A (en) * | 2012-08-29 | 2014-03-26 | 飞思卡尔半导体公司 | Data processor device for handling a watchpoint and method thereof |
| CN104239201A (en) * | 2013-06-20 | 2014-12-24 | 上海博达数据通信有限公司 | Memory read-write monitoring method in flexible single-step system |
| CN104252402A (en) * | 2014-09-05 | 2014-12-31 | 深圳创维数字技术有限公司 | Program debugging method and device |
| CN106776208A (en) * | 2016-12-02 | 2017-05-31 | 中国航天系统科学与工程研究院 | Fault Locating Method during a kind of running software |
| CN108829591A (en) * | 2018-05-31 | 2018-11-16 | 北京理工大学 | A kind of synergic debugging system and method based on Web |
Non-Patent Citations (2)
| Title |
|---|
| M. L. Corliss等.Low-overhead interactive debugging via dynamic instrumentation with DISE.11th International Symposium on High-Performance Computer Architecture.2005,303-314. * |
| 程佳.嵌入式共享远程调试技术的研究与实现.《中国优秀硕士学位论文全文数据库信息科技辑》.2011,(第12期),I137-46. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110727577A (en) | 2020-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Cui et al. | {REPT}: Reverse debugging of failures in deployed software | |
| Carreira et al. | Xception: Software fault injection and monitoring in processor functional units | |
| US7950001B2 (en) | Method and apparatus for instrumentation in a multiprocessing environment | |
| Kahlon et al. | Fast and accurate static data-race detection for concurrent programs | |
| CN110580226B (en) | Object code coverage rate testing method, system and medium for operating system level program | |
| US9152531B2 (en) | Post-compile instrumentation of object code for generating execution trace data | |
| US8266608B2 (en) | Post-compile instrumentation of object code for generating execution trace data | |
| US8185875B2 (en) | Fast and accurate static data-race detection for concurrent programs | |
| TWI544410B (en) | Diagnosing code using single step execution | |
| US10095611B1 (en) | Methodology for unit test and regression framework | |
| US20080307397A1 (en) | Program Analysis by Partial Emulation | |
| US11113182B2 (en) | Reversible debugging in a runtime environment | |
| CN110727577B (en) | Debugging method, system and medium for probability reproduction problem in embedded system software | |
| Natella et al. | Emulation of transient software faults for dependability assessment: A case study | |
| US8819641B1 (en) | Program state reversing software development tool | |
| US11074153B2 (en) | Collecting application state in a runtime environment for reversible debugging | |
| Long et al. | Mutation-based exploration of a method for verifying concurrent Java components | |
| US7100027B1 (en) | System and method for reproducing system executions using a replay handler | |
| CN112740187A (en) | Method and system for debugging program | |
| KR101685299B1 (en) | Automated testing method and apparatus for program processable non-deterministic events | |
| Park et al. | Post-silicon bug localization for processors using IFRA | |
| WO2021247074A1 (en) | Resumable instruction generation | |
| Arya et al. | Semi-automated debugging via binary search through a process lifetime | |
| Osinski et al. | PyFI-fault injection platform for real hardware | |
| Zhao et al. | Towards Understanding Bugs in WSN Applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |