Embedded system crash diagnosis method and system

Abstract

The invention provides a crash diagnosis method and system for an embedded system, and the method comprises the steps: carrying out the filling of data in a specified format in a stack space of the embedded system in an initialization process, and enabling the data to be filled from a stack starting address; when it is detected that the embedded system crashes, stack top data of a preset length of the stack space is read; and comparing the stack top data with the data in the specified format, and if the stack top data is different from the data in the specified format, judging that the crash reason is stack overflow. Through the scheme of the embodiment of the invention, the data in the specified format can be filled in the stack space of the embedded system, so that after the crash, whether the reason of the crash is stack overflow can be judged only by checking whether the data in the specified format in the stack space is changed or not or whether the variable initial value of the database is changed or not; therefore, the quick judgment of the crash reason is realized, and the problem of low diagnostic efficiency of the crash reason of the current embedded system is solved.

Description

Technical Field

[0001] The present application relates to the field of information technology, and in particular to a method and system for diagnosing a crash of an embedded system. Background Art

[0002] System crashes are a common and thorny issue in embedded system development. When a system crashes, the program counter (PC) often points to code within a third-party library. However, this doesn't necessarily mean the root cause lies with the third-party library itself. Crashes can be caused by several scenarios: External code tampering with variable data in a third-party library: In embedded systems, multiple modules or tasks may share global variables or dynamically allocated memory. If external code accesses or tampered with variable data in a third-party library, it can cause the library to fail during subsequent execution, ultimately leading to a system crash. Stack overflow or heap memory corruption: Embedded systems typically have limited resources, with fixed stack and heap memory sizes. If a program's function call hierarchy is too deep or local variables occupy too much stack space, insufficient stack space may result, leading to a stack overflow. A stack overflow can tamper with function return addresses, local variables, and other data, causing program execution errors and accessing illegal addresses. Furthermore, improper heap usage, such as allocating too little heap space or causing memory leaks, can also cause variables at other addresses to be tampered with, ultimately leading to a system crash.

[0003] However, when developers encounter an embedded system crash and the crash location points to a third-party library, they often use methods such as call stack backtracing (Backtrace), memory protection unit (MPU) hardware detection, traditional log printing and breakpoint debugging to detect it. These methods are not only inefficient but also prone to missing key information. Summary of the Invention

[0004] The purpose of the embodiments of the present application is to provide a method and system for diagnosing a crash of an embedded system, so as to solve the problem of low efficiency in the process of diagnosing a crash of an embedded system. The specific technical solution is as follows:

[0005] In a first aspect of an embodiment of the present application, a method for diagnosing a crash of an embedded system is provided, the method comprising:

[0006] During the initialization process, the stack space of the embedded system is filled with data in a specified format, wherein the order of filling the data is to start from the stack starting address;

[0007] When the embedded system is detected to be dead, reading the top data of the stack space of a preset length;

[0008] The stack top data is compared with the data in the specified format. If they are different, it is determined that the cause of the crash is stack overflow.

[0009] In a possible implementation, filling the stack space of the embedded system with data in a specified format includes:

[0010] Identifying the starting address and size of the stack space of the embedded system;

[0011] Calculating the amount of data to be filled according to the size of the stack space;

[0012] The stack space is filled with data in a specified format according to the starting position of the stack space and the calculated amount of data to be filled.

[0013] In a possible implementation, after filling the stack space of the embedded system with data in a specified format during the initialization process, the method further includes:

[0014] Identify the third-party communication library address;

[0015] According to the identified third-party communication library address, identifying and mirroring the initial values ​​of each variable in the third-party communication library;

[0016] Identify the current value of each variable in the third-party communication library once every preset time interval;

[0017] Compare the initial value of each variable with the current value of each variable;

[0018] Determine whether variable tampering occurs based on the comparison results.

[0019] In one possible implementation, the comparison result includes inconsistent variables and addresses;

[0020] After comparing the initial value of each variable with the current value of each variable, the method further includes:

[0021] By using the monitoring point pre-set in the code, the current value of the variable corresponding to the monitoring point is identified;

[0022] The current value of the variable corresponding to the monitoring point is compared with the historical value of the variable corresponding to the monitoring point to obtain the location information of the variable tampering.

[0023] In a possible implementation, after filling the stack space of the embedded system with data in a specified format during the initialization process, the method further includes:

[0024] Identifying a pointer and size of an allocated memory block in the embedded system;

[0025] Record the identified pointers and sizes into the monitoring table;

[0026] Get the current pointer and size of each memory block once every preset time interval;

[0027] The current pointer and size information is compared with the pointer and size recorded in the monitoring table to determine whether there is an abnormality in the embedded system.

[0028] According to a second aspect of the present application, a system for diagnosing a system crash in an embedded system is provided, the system comprising:

[0029] The data filling module is used to fill the stack space of the embedded system with data of a specified format during the initialization process, wherein the order of filling the data is to start from the stack starting address;

[0030] A data reading module, configured to read the top data of a preset length from the stack space when a crash of the embedded system is detected;

[0031] The cause judgment module is used to compare the stack top data with the data in the specified format. If they are different, it is determined that the cause of the crash is stack overflow.

[0032] In one possible implementation, the cause judgment module is specifically used to identify the starting address and size of the stack space of the embedded system; calculate the amount of data to be filled based on the size of the stack space; and fill the stack space with data in a specified format based on the starting position of the stack space and the calculated amount of data to be filled.

[0033] In a possible implementation, the system further includes:

[0034] The tampering identification module is used to identify the address of a third-party communication library; based on the identified third-party communication library address, identify the initial value of each variable in the third-party communication library and mirror it; identify the current value of each variable in the third-party communication library once every preset time interval; compare the initial value of each variable with the current value of each variable; and determine whether variable tampering has occurred based on the comparison result.

[0035] In one possible implementation, the comparison result includes inconsistent variables and addresses; and the system further includes:

[0036] The tampering location module is used to identify the current value of the variable corresponding to the monitoring point set in advance in the code; compare the current value of the variable corresponding to the monitoring point with the historical value of the variable corresponding to the monitoring point to obtain the location information of the variable tampering.

[0037] In a possible implementation, the system further includes:

[0038] The abnormality identification module is used to identify the pointer and size of the allocated memory block in the embedded system; record the identified pointer and size in a monitoring table; obtain the current pointer and size of each memory block once every preset time interval; compare the current pointer and size information with the pointer and size recorded in the monitoring table to determine whether there is an abnormality in the embedded system.

[0039] Another aspect of the present invention provides a smart door lock, comprising:

[0040] Memory for storing computer programs;

[0041] The processor is used to implement any of the above-mentioned methods for diagnosing a crash of an embedded system when executing a program stored in the memory.

[0042] In another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the computer program implements any of the above-mentioned methods for diagnosing a crash of an embedded system.

[0043] In another aspect of the embodiments of the present application, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute any of the above-mentioned methods for diagnosing a crash of an embedded system.

[0044] Beneficial effects of the embodiments of the present application:

[0045] The embodiment of the present application provides a method and system for diagnosing a crash of an embedded system, the method comprising: during the initialization process, filling the stack space of the embedded system with data in a specified format, wherein the order of filling the data is to start filling from the stack starting address; when the embedded system is detected to be crashed, reading the stack top data of a preset length of the stack space; comparing the stack top data with the data in the specified format, and if they are different, determining that the cause of the crash is a stack overflow. Through the scheme of the embodiment of the present application, the stack space of the embedded system can be filled with data in a specified format, so that after the crash, it is only necessary to check whether the data in the specified format in the stack space has changed or whether the initial value of the variable in the database has changed, to determine whether the cause of the crash is a stack overflow, thereby achieving rapid judgment of the cause of the crash and solving the problem of low efficiency in diagnosing the cause of the crash of the current embedded system.

[0046] Of course, it is not necessary to achieve all the advantages described above at the same time when implementing any product or method of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

[0048] Figure 1 A schematic diagram of a flowchart of a method for diagnosing a crash of an embedded system provided in an embodiment of the present application;

[0049] Figure 2 A schematic diagram of a flow chart of dynamic stack overflow detection provided in an embodiment of the present application;

[0050] Figure 3 A schematic diagram of a process for determining variable tampering provided in an embodiment of the present application;

[0051] Figure 4 A schematic diagram of a flow chart for determining variable tampering provided in an embodiment of the present application;

[0052] Figure 5 A schematic diagram of a process for abnormality determination provided in an embodiment of the present application;

[0053] Figure 6 A schematic diagram of a process for abnormality determination provided in an embodiment of the present application;

[0054] Figure 7 A schematic diagram of the structure of a crash diagnosis system for an embedded system provided in an embodiment of the present application;

[0055] Figure 8 A schematic diagram of the structure of the smart door lock provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field based on this application are within the scope of protection of this application.

[0057] In a first aspect of the embodiment of the present application, a method for diagnosing a crash of an embedded system is first provided. Figure 1 , Figure 1 A flowchart of a method for diagnosing a crash of an embedded system provided in an embodiment of the present application is provided, wherein the method includes:

[0058] Step S11, during the initialization process, the stack space of the embedded system is filled with data in a specified format, wherein the order of filling the data is to start from the stack starting address;

[0059] Step S12, when the embedded system is detected to be frozen, reading the top data of the stack space of a preset length;

[0060] Step S13: Compare the data on the top of the stack with the data in the specified format. If they are different, it is determined that the cause of the crash is stack overflow.

[0061] Corresponding to the above-mentioned step S11, during the initialization process, the stack space of the embedded system is filled with data of a specified format, which can be filled during the system initialization process. The specified format can be set according to actual conditions, and it only needs to be easy to identify and compare. For example, it can be 0xFFFFFFFF. In an embodiment of the present application, the order of filling the data is to start filling from the stack starting address. Specifically, the pointer operation in the C language can be used. It can start from the bottom of the stack and fill in bytes or words (according to the system architecture), and the length of the filled data can also be set. In actual use, after the filling is completed, relevant information of the stack space filling, such as the filling mode, the filling start time, etc., can also be recorded for reference during subsequent detection.

[0062] Corresponding to step S12, when the embedded system crash is detected, a preset length of top-of-stack data is read from the stack space. Specifically, when the system crash is triggered, this can be accomplished by obtaining the current top-of-stack pointer position and then reading a system-specific register or memory location. Different embedded systems may use different acquisition methods. Starting from the top-of-stack pointer position, a predetermined number of bytes of remaining data at the top of the stack are read. The predetermined number of bytes can be the same as the length of the data in the aforementioned filling process, for example, 4 bytes, which can be determined based on the data type of the filling pattern.

[0063] Corresponding to step S13 above, when comparing the data at the top of the stack with the data in the specified format, the remaining data at the top of the stack can be compared with the pre-populated data in the specified format. If the data are inconsistent, i.e., the data in the specified format is corrupted, a stack overflow is determined. If the data are consistent, the possibility of a stack overflow causing the system crash can be ruled out.

[0064] In actual use, the stack is a block of memory allocated from the chip's random access memory (RAM), allocated and released by the system. Generally, when writing a function, memory for defined local variables, arrays, pointers, structures, and so on is allocated only when the chip executes the function. Once the function completes, the memory is released by the system, and the memory occupied by these variables after allocation is considered stack space. Stack space addresses grow from highest to lowest, in a first-in, last-out (FIFO) fashion. Therefore, a stack overflow can cause the data at the bottom of the stack to change.

[0065] It can be seen that through the solution of the embodiment of the present application, data in a specified format can be filled in the stack space of the embedded system. Therefore, after a crash, it is only necessary to check whether the data in the specified format in the stack space has changed or whether the initial value of the variable in the database has changed to determine whether the cause of the crash is a stack overflow, thereby achieving rapid judgment of the cause of the crash and solving the problem of low efficiency in diagnosing the cause of the crash of the current embedded system.

[0066] In one possible implementation, the filling of the stack space of the embedded system with data in a specified format includes: identifying the starting address and size of the stack space of the embedded system; calculating the amount of data to be filled based on the size of the stack space; and filling the stack space with data in a specified format based on the starting position of the stack space and the calculated amount of data to be filled. Specifically, the starting address and size of the stack space of the embedded system can be identified by determining the boundary information of the stack space through an interface function provided by the system or according to chip architecture and operating system-related specifications to obtain the starting address and size of the stack space. The amount of data to be filled can be calculated based on the size of the stack space. The amount of data to be filled can be calculated based on the size of the stack space, which is generally 4 bytes in this application. When filling the stack space with data in a specified format based on the starting position of the stack space and the calculated amount of data to be filled, the growth direction of the stack space address is taken into account (mostly from high to low). Therefore, the order of filling the data in this application is to start filling from the starting address of the stack.

[0067] For an example, see Figure 2 , dynamic detection of stack overflow, including:

[0068] 1. Initialize the stack space fill pattern to 0xFFFFFFFF. During system initialization, according to the chip manual and the hardware configuration of the development board, call relevant system functions to obtain the starting address and size of the stack space. For example, use the __get_MSP() function (a function used to obtain the current value of the main stack pointer) to obtain the main stack pointer (i.e., the top of the stack address). Combined with the stack size information defined in the linker script, the stack space boundary is determined. Based on the stack space size, the amount of fill data is calculated. Since the stack space address grows from high to low, filling is started from the stack starting address. Using loops and pointer operations in the C language (a programming language), the specific pattern 0xFFFFFFFF is written to the stack space in units of words. After filling is completed, the fill pattern and the filling start time are recorded.

[0069] 2. System crash: When the system crashes, the crash information is obtained to trigger subsequent detection steps.

[0070] 3. Check the remaining data at the top of the stack; you can get the current top of the stack pointer position by reading the get_MSP() function, and start reading a certain byte length of the remaining data at the top of the stack from this position.

[0071] 4. Determine whether the pattern value has been corrupted by comparing the remaining data at the top of the stack with the pre-filled 0xFFFFFFFF pattern. If the data is inconsistent, indicating it has not been corrupted, the stack has not overflowed. If it is corrupted, the stack has overflowed. Based on the recorded information, the approximate time range of the stack overflow can be preliminarily determined, providing clues for subsequent analysis.

[0072] In a possible implementation, after the stack space of the embedded system is filled with data in a specified format during the initialization process, see Figure 3 , Figure 3 A schematic diagram of a flow chart for determining variable tampering provided in an embodiment of the present application, wherein the method further includes:

[0073] Step S31, identifying the third-party communication library address;

[0074] Step S32, identifying and mirroring the initial values ​​of the variables in the third-party communication library according to the identified third-party communication library address;

[0075] Step S33, identifying the current value of each variable in the third-party communication library once every preset time interval;

[0076] In step S34, the initial value of each variable is compared with the current value of each variable. If they are different, it is determined that variable tampering has occurred.

[0077] Since a system crash may also occur when external code tampers with variable data in a third-party library at other locations, embodiments of the present application can also identify variable tampering to determine the cause of the crash. Specifically, identifying the address of the third-party communication library can generate a map file (an image data call file) containing symbol information when compiling the embedded system program. It can also be required to ensure that the map file contains detailed address information of the third-party library's global variables. Specifically, this can be ensured by setting relevant compiler parameters. The map file is then parsed, and the starting and ending addresses of the third-party library's global variables in memory are located by searching for specific symbol tables or text keywords, thereby determining the address range. The located address range information is then stored in a data structure, such as an array or a linked list, to facilitate quick access during subsequent operations; the address range information is then verified to ensure its accuracy. By comparing with the third-party library's documentation or known variable layout information, subsequent monitoring deviations caused by map file parsing errors can be avoided. When identifying the initial values ​​of each variable in the third-party communication library based on the identified third-party communication library address, a memory copy area that is completely consistent with the monitored variable can be opened in the memory as a mirror storage area based on the located third-party library global variable address range. Specifically, you can use a memory allocation function (such as malloc (memory allocation, dynamic memory allocation) in the C language) to allocate sufficient memory space, and then copy the initial values ​​of the third-party library's global variables to the mirror storage area. Copy the values ​​byte by byte or variable by variable in the order of their addresses to ensure that the data in the mirror storage area is completely consistent with the original variable data.

[0078] Among them, the current value of each variable in the third-party communication library is identified once every preset time interval, and the identification can be performed by setting a periodic task. Specifically, a timer can be set to periodically trigger the comparison operation. In actual use, the comparison cycle can be reasonably set according to system performance and monitoring requirements, such as every 100, 80, or 150 milliseconds as a cycle. The initial value of each variable and the current value of each variable are compared, and the comparison can also be performed through the periodic task, and the comparison is performed after the current value is periodically identified. In the timer interrupt service program, the current value of the global variable of the third-party library is compared with the data in the mirror storage area. The comparison results are recorded. If inconsistent variables are found, the variable and its address are marked, and it is determined that variable tampering has occurred.

[0079] In one possible embodiment, the comparison results include inconsistent variables and addresses. After comparing the initial value of each variable with its current value, the method further includes: identifying the current value of the variable corresponding to the monitoring point through a pre-set monitoring point in the code; and comparing the current value of the variable corresponding to the monitoring point with the historical value of the variable corresponding to the monitoring point to obtain location information of the variable tampering. Specifically, the embedded system's business logic can be analyzed to identify key code segments that may access or modify third-party library variables. For example, these may include code regions involving third-party library function calls, shared resource operations, etc. Monitoring points pre-set in the code are used to identify the inconsistent variables and addresses, and their corresponding locations, specifically, the corresponding functions or lines of code. Monitoring points can be pre-set at the start and end of key code segments. Monitoring points can be implemented by inserting specific function calls or macro definitions in the code. These functions or macros are used to record data consistency verification location markers. When the program executes at a monitoring point, the current value of the relevant third-party library variable is obtained and a difference analysis is performed with the value recorded at the previous monitoring point. Specifically, a hash algorithm or a simple byte-by-byte comparison method can be used to quickly locate the interval where the variable value changes. If abnormal changes in variable values ​​are detected within a critical code segment, the tampering interval can be further narrowed down by combining the function call stack information and attempting to locate the specific function or code line.

[0080] For an example, see Figure 4 , Figure 4 A flow chart of variable tampering determination provided in an embodiment of the present application includes:

[0081] 1. Read the map file to locate the address range of global variables. When compiling the project, set the compiler parameters to generate a map file containing symbol information. Ensure that it contains the detailed address information of the third-party communication library's global variables. Use a parsing tool or a custom script to parse the map file and find the starting and ending addresses of the third-party communication library's global variables in memory. Once the address range is determined, store it in an array for subsequent access. Also, compare the address range with the third-party communication library's documentation to verify the accuracy of the address range.

[0082] 2. Establish a mirror storage area; open a mirror storage area in memory that is consistent with the monitored variables, use the malloc function to apply for memory space, and copy the initial values ​​of the third-party communication library global variables one by one to the mirror storage area.

[0083] 3. Periodically compare variables with mirrored data. Set a timer to trigger the comparison every 100 milliseconds, based on system performance and the frequency of communication data changes. In the timer interrupt service routine, compare the current value of the third-party communication library's global variables with the mirrored storage area data. If any inconsistencies are found, mark the variable and its address.

[0084] 4. Insert monitoring points before and after key code sections. Analyze the system's business logic to identify key code sections involving third-party communication library function calls and data processing, such as those within data sending and receiving functions. Set monitoring points by inserting macro definitions at the beginning and end of these key code sections.

[0085] 5. Difference analysis locates the tampered section. When the program reaches the monitoring point, the current value of the third-party communication library's related variables is obtained and compared byte by byte with the value recorded at the previous monitoring point for difference analysis. If an abnormal change in the variable value is detected within a critical code section, the function call stack information is combined to further locate the specific function and code line, determining the possible location of the variable tampering.

[0086] In a possible implementation, after the stack space of the embedded system is filled with data in a specified format during the initialization process, see Figure 5 , Figure 5 A schematic diagram of a flow chart of abnormality determination provided in an embodiment of the present application, wherein the method further includes:

[0087] Step S51, identifying the pointer and size of the allocated memory block in the embedded system;

[0088] Step S52, recording the identified pointer and size into a monitoring table;

[0089] Step S53: Obtain the current pointer and size of each memory block once every preset time interval;

[0090] Step S54 : Compare the current pointer and size information with the pointer and size recorded in the monitoring table to determine whether there is an abnormality in the embedded system.

[0091] Specifically, identifying the pointer and size of allocated memory blocks in the embedded system can be done by writing functions. For example, custom malloc and free functions (a dynamic memory release function) can be written. The original malloc and free functions are retained within the custom functions, while recording functions are added. For example, function pointers can be used to store the addresses of the system's default malloc and free functions so that they can be called from the custom function.

[0092] Record the identified pointers and sizes in a monitoring table. In a custom malloc function, when memory allocation is successful, record the allocated pointer and size in the monitoring table. The monitoring table can be an array of structures, with each element recording information about a single memory allocation. In a custom free function, when memory is released, delete the corresponding allocation record from the monitoring table. Ensure that the monitoring table always records the currently valid memory allocation information. In actual use, to ensure the accuracy and timeliness of records, add a mutex lock mechanism to monitoring table operations. This prevents concurrent access to the monitoring table in a multi-threaded or multi-tasking environment from causing data errors.

[0093] At preset intervals, obtain the current pointer and size of each memory block. This can be accomplished by setting a periodic check task, which can be implemented using the system's timer interrupt or task scheduling mechanism. Similarly, set a reasonable check interval based on system performance and memory usage, such as checking every 1 second. During each check, traverse all memory allocation records in the monitoring table and obtain the pointer and size information for each allocated memory block.

[0094] The current pointer and size information is compared with the pointer and size recorded in the monitoring table to determine whether the embedded system has any abnormalities. Specifically, the integrity of the dynamic memory content can be checked based on the pointer and size of the memory block. This can be done by calculating the checksum of the memory block and comparing it with the pre-saved checksum; or by checking whether there is illegal data at the memory block boundary (such as access traces that exceed the allocated size). If an abnormality in the integrity of the memory content is found, relevant information such as the abnormal memory block pointer, size, and abnormality type is recorded, and the corresponding error handling mechanism is triggered, such as printing an error log, sending an alarm signal, etc.

[0095] For an example, see Figure 6 , Figure 6 A schematic diagram of a process for abnormality determination provided in an embodiment of the present application includes:

[0096] 1. Overload the malloc / free function. Specifically, you can write your own malloc and free functions, use function pointers inside your own functions to save the addresses of the system's default malloc and free functions, so as to call the original functions and add a logging function.

[0097] 2. Record the allocation pointer and size in the monitoring table; in the custom malloc function, when the memory is allocated successfully, record the allocated pointer and size in the monitoring table (defined as a structure array); in the custom free function, delete the corresponding record from the monitoring table when the memory is released, and add a mutex mechanism to prevent data errors in a multi-threaded environment.

[0098] 3. Periodically check dynamic memory contents. Utilize the STM32 (a single-chip microcontroller) timer interrupt mechanism to set a periodic check task to execute every 1 second. During each check, iterate through the memory allocation records in the monitoring table to obtain the pointer and size information of each memory block.

[0099] 4. Detect memory out-of-bounds; verify the integrity of dynamic memory contents by calculating the CRC (cyclic redundancy check) checksum of the memory block and comparing it with the pre-saved checksum, or checking whether there is illegal data at the memory block boundary.

[0100] 5. Trace the malloc / free call chain; if any memory integrity anomalies are found, record the abnormal memory block pointer, size, anomaly type, and other information, and trigger the error handling mechanism, such as printing error logs through the serial port, to help developers find and handle problems in a timely manner.

[0101] The inventors discovered that, through the aforementioned specific implementation, they successfully utilized the diagnostic method and system of the present invention in an IoT device project, quickly locating the system crash as a result of excessive stack space occupied by local variables in a third-party communication library during high-concurrency data transmission, leading to stack overflows and memory out-of-bounds errors during dynamic memory allocation. Based on these findings, the developers optimized function call and memory allocation strategies, effectively resolving the crash issue and improving system stability and reliability.

[0102] In a second aspect of the embodiment of the present application, a crash diagnosis system for an embedded system is provided. Figure 7 , Figure 7 A schematic diagram of a crash diagnosis system for an embedded system provided in an embodiment of the present application is provided, wherein the system includes:

[0103] The data filling module 701 is used to fill the stack space of the embedded system with data in a specified format during the initialization process, wherein the order of filling the data is to start from the stack starting address;

[0104] A data reading module 702 is configured to read the top data of the stack space of a preset length when a crash of the embedded system is detected;

[0105] The cause determination module 703 is configured to compare the stack top data with the data in the specified format. If they are different, the cause of the crash is determined to be stack overflow.

[0106] In one possible implementation, the cause judgment module is specifically used to identify the starting address and size of the stack space of the embedded system; calculate the amount of data to be filled based on the size of the stack space; and fill the stack space with data in a specified format based on the starting position of the stack space and the calculated amount of data to be filled.

[0107] In a possible implementation, the system further includes:

[0108] The tampering identification module is used to identify the address of a third-party communication library; based on the identified third-party communication library address, identify the initial value of each variable in the third-party communication library and mirror it; identify the current value of each variable in the third-party communication library once every preset time interval; compare the initial value of each variable with the current value of each variable; and determine whether variable tampering has occurred based on the comparison result.

[0109] In one possible implementation, the comparison result includes inconsistent variables and addresses; and the system further includes:

[0110] The tampering location module is used to identify the current value of the variable corresponding to the monitoring point set in advance in the code; compare the current value of the variable corresponding to the monitoring point with the historical value of the variable corresponding to the monitoring point to obtain the location information of the variable tampering.

[0111] In a possible implementation, the system further includes:

[0112] The abnormality identification module is used to identify the pointer and size of the allocated memory block in the embedded system; record the identified pointer and size in a monitoring table; obtain the current pointer and size of each memory block once every preset time interval; compare the current pointer and size information with the pointer and size recorded in the monitoring table to determine whether there is an abnormality in the embedded system.

[0113] It can be seen that through the solution of the embodiment of the present application, data in a specified format can be filled in the stack space of the embedded system. Therefore, after a crash, it is only necessary to check whether the data in the specified format in the stack space has changed or whether the initial value of the variable in the database has changed to determine whether the cause of the crash is a stack overflow, thereby achieving rapid judgment of the cause of the crash and solving the problem of low efficiency in diagnosing the cause of the crash of the current embedded system.

[0114] The present application also provides a smart door lock. Figure 8 Shown, including:

[0115] Memory 801, used for storing computer programs;

[0116] The processor 802 is configured to execute the program stored in the memory 801 by performing the following steps:

[0117] During the initialization process, the stack space of the embedded system is filled with data in a specified format, wherein the order of filling the data is to start from the stack starting address;

[0118] When the embedded system is detected to be dead, reading the top data of the stack space of a preset length;

[0119] The stack top data is compared with the data in the specified format. If they are different, it is determined that the cause of the crash is stack overflow.

[0120] The communication bus mentioned in the smart door lock can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0121] The communication interface is used for communication between the above-mentioned smart door lock and other devices.

[0122] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage. Alternatively, the memory may be at least one storage device located away from the processor.

[0123] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0124] In another embodiment provided by the present application, a computer-readable storage medium is further provided, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0125] In another embodiment provided by the present application, a computer program product including instructions is also provided, which, when executed on a computer, enables the computer to execute any one of the methods in the above embodiments.

[0126] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a solid-state drive (SSD).

[0127] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0128] Each embodiment in this specification is described in a related manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system, smart door lock, and storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For related parts, refer to the descriptions of the method embodiments.

[0129] The above description is only a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application are included in the scope of protection of the present application.

Claims

1. A method for diagnosing a crash of an embedded system, characterized in that: The method comprises: During the initialization process, the stack space of the embedded system is filled with data in a specified format, wherein the order of filling the data is to start from the stack starting address; When the embedded system is detected to be dead, reading the top data of the stack space of a preset length; The stack top data is compared with the data in the specified format. If they are different, it is determined that the cause of the crash is stack overflow.

2. The method according to claim 1, characterized in that The filling of the stack space of the embedded system with data in a specified format includes: Identifying the starting address and size of the stack space of the embedded system; Calculating the amount of data to be filled according to the size of the stack space; The stack space is filled with data in a specified format according to the starting position of the stack space and the calculated amount of data to be filled.

3. The method according to claim 1, characterized in that After filling the stack space of the embedded system with data in a specified format during the initialization process, the method further includes: Identify the third-party communication library address; According to the identified third-party communication library address, identifying and mirroring the initial values ​​of each variable in the third-party communication library; Identify the current value of each variable in the third-party communication library once every preset time interval; Compare the initial value of each variable with the current value of each variable; Determine whether variable tampering occurs based on the comparison results.

4. The method according to claim 3, characterized in that The comparison results include inconsistent variables and addresses; After comparing the initial value of each variable with the current value of each variable, the method further includes: By using the monitoring point pre-set in the code, the current value of the variable corresponding to the monitoring point is identified; The current value of the variable corresponding to the monitoring point is compared with the historical value of the variable corresponding to the monitoring point to obtain the location information of the variable tampering.

5. The method according to claim 1, wherein After filling the stack space of the embedded system with data in a specified format during the initialization process, the method further includes: Identifying a pointer and size of an allocated memory block in the embedded system; Record the identified pointers and sizes into the monitoring table; Get the current pointer and size of each memory block once every preset time interval; The current pointer and size information is compared with the pointer and size recorded in the monitoring table to determine whether there is an abnormality in the embedded system.

6. A crash diagnosis system for an embedded system, characterized in that: The system comprises: The data filling module is used to fill the stack space of the embedded system with data of a specified format during the initialization process, wherein the order of filling the data is to start from the stack starting address; A data reading module, configured to read the top data of a preset length from the stack space when a crash of the embedded system is detected; The cause judgment module is used to compare the stack top data with the data in the specified format. If they are different, it is determined that the cause of the crash is stack overflow.

7. The system according to claim 6, characterized in that The cause judgment module is specifically used to identify the starting address and size of the stack space of the embedded system; calculate the amount of data to be filled according to the size of the stack space; and fill the stack space with data in a specified format according to the starting position of the stack space and the calculated amount of data to be filled.

8. The system according to claim 6, wherein: The system further comprises: The tampering identification module is used to identify the address of a third-party communication library; based on the identified third-party communication library address, identify the initial value of each variable in the third-party communication library; identify the current value of each variable in the third-party communication library once every preset time interval and mirror it; compare the initial value of each variable with the current value of each variable; and determine whether variable tampering has occurred based on the comparison result.

9. A smart door lock, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the method according to any one of claims 1 to 5 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

Images