CN120704925A

CN120704925A - Crash diagnosis method and system for embedded system

Info

Publication number: CN120704925A
Application number: CN202510793678.8A
Authority: CN
Inventors: 李浚; 汪志煌; 龚凯安; 蔡伟杰
Original assignee: Xiamen Leelen Technology Co Ltd
Current assignee: Xiamen Leelen Technology Co Ltd
Priority date: 2025-06-13
Filing date: 2025-06-13
Publication date: 2025-09-26

Abstract

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.

Description

Crash diagnosis method and system for embedded system

Technical Field

The application relates to the technical field of information, in particular to a crash diagnosis method and system of an embedded system.

Background

In embedded system development, system crashes are a common and troublesome problem. When the system crashes, the program counter (PC value) will typically point to the code location inside the third party library. However, this does not mean that the root cause of the crash must be identified in the third party library itself. In practice, a crash may be caused by external code tampering with variable data of a third party library, where multiple modules or tasks may share global variables or dynamically allocated memory. If the external code accesses or falsifies variable data of the third party library beyond the boundary at other positions, the third party library may be abnormal in subsequent operation, and finally the system is halted. Stack overflow or heap memory corruption-embedded systems are typically resource limited, with stack space and heap space being fixed in size. If the function call hierarchy of the program is too deep, or the stack space occupied by the local variables is too large, insufficient stack space may be caused, and stack overflow may occur. Stack overflow can tamper with the return address, local variables, etc. of the function, thereby causing program operation exception and accessing illegal addresses. In addition, improper use of heap space, such as too small heap space or memory leakage, may also cause other address variables to be tampered with, ultimately causing system crashes.

However, when a developer encounters a crash of the embedded system and the crash position points to a third party library, the method of call stack backtracking (Backtrace), memory Protection Unit (MPU) hardware detection, traditional log printing, breakpoint debugging and the like is often adopted for detection, and the method has low detection efficiency and is easy to miss key information.

Disclosure of Invention

The embodiment of the application aims to provide a method and a system for diagnosing the crash of an embedded system, which are used for solving the problem of low efficiency in the process of diagnosing the crash of the embedded system. The specific technical scheme is as follows:

In a first aspect of the embodiment of the present application, there is provided a crash diagnosis method for an embedded system, the method including:

in the initialization process, filling data in a specified format into a stack space of the embedded system, wherein the filling sequence of the data is that filling is started from a stack start address;

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

And comparing the stack top data with the data in the specified format, and if the stack top data and the data in the specified format are different, judging that the crash source is stack overflow.

In one possible implementation manner, the filling of the stack space of the embedded system with the data in the specified format includes:

Identifying a starting address and a size of a stack space of the embedded system;

calculating the data quantity to be filled according to the size of the stack space;

And filling the stack space with data in a specified format according to the initial position of the stack space and the calculated data quantity to be filled.

In one possible implementation manner, after the filling of the stack space of the embedded system with the data in the specified format in the initializing process, the method further includes:

identifying a third party communication library address;

According to the identified address of the third party communication library, identifying the initial value of each variable in the third party communication library and mirroring;

identifying the current value of each variable in the third party communication library once every preset time length;

comparing the initial value of each variable with the current value of each variable;

And judging whether variable tampering occurs according to the comparison result.

In one possible implementation, the comparison result includes an inconsistent variable and an address;

after comparing the initial value of each variable with the current value of each variable, the method further comprises:

Identifying the current value of a variable corresponding to a monitoring point through the monitoring point preset in the code;

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 the tampered position information of the variable.

identifying pointers and sizes of allocated memory blocks in the embedded system;

Recording the identified pointer and size into a monitoring table;

Acquiring the current pointer and the current size of each memory block once every interval of preset time length;

and comparing the current pointer and the current size information with the pointer and the current size recorded in the monitoring table, and judging whether the embedded system is abnormal or not.

In a second aspect of the embodiment of the present application, there is provided a crash diagnosis system of an embedded system, the system including:

The data filling module is used for filling data with a specified format into a stack space of the embedded system in the initialization process, wherein the filling sequence of the data is that the data is filled from a stack start address;

The data reading module is used for reading stack top data with preset length of the stack space when the embedded system is detected to be dead;

and the reason judging module is used for comparing the stack top data with the data in the appointed format, and judging that the crash reason is stack overflow if the stack top data is different from the data in the appointed format.

In one possible implementation manner, the reason judging module is specifically configured to identify a start address and a size of a stack space of the embedded system, calculate an amount of data to be filled according to the size of the stack space, and fill data in a specified format in the stack space according to the start position of the stack space and the calculated amount of data to be filled.

In one possible embodiment, the system further comprises:

The system comprises a tamper identification module, a mirror image generation module, a tamper detection module and a tamper detection module, wherein the tamper identification module is used for identifying a third party communication library address, identifying initial values of variables in the third party communication library according to the identified third party communication library address, mirroring the initial values of the variables in the third party communication library, identifying current values of the variables in the third party communication library once every preset time, comparing the initial values of the variables with the current values of the variables, and judging whether the variables are tampered according to comparison results.

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

the tampering locating module is used for identifying the current value of the variable corresponding to the monitoring point through the monitoring point preset 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 the tampered position information of the variable.

In one possible embodiment, the system further comprises:

The system comprises an embedded system, an abnormality identification module, a monitoring table, a comparison module and a control module, wherein the embedded system is used for storing the current pointers and the magnitudes of memory blocks, the abnormality identification module is used for identifying the pointers and the magnitudes of the allocated memory blocks in the embedded system, recording the identified pointers and magnitudes into the monitoring table, acquiring the current pointers and the magnitudes of the memory blocks once every preset time, comparing the current pointer and the magnitude information with the pointers and the magnitudes recorded in the monitoring table, and judging whether the embedded system has abnormality or not.

In another aspect of the embodiment of the present application, there is also provided an intelligent door lock, including:

a memory for storing a computer program;

and the processor is used for realizing the crash diagnosis method of any embedded system when executing the program stored in the memory.

In another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium having stored therein a computer program that, when executed by a processor, implements the crash diagnosis method of any one of the embedded systems described above.

In another aspect of the embodiments of the present application, there is also provided a computer program product containing instructions that, when run on a computer, cause the computer to perform a method of crash diagnosis of any of the embedded systems described above.

The embodiment of the application has the beneficial effects that:

The embodiment of the application provides a method and a system for diagnosing a dead halt of an embedded system, wherein the method comprises the steps of filling data in a specified format into a stack space of the embedded system in an initialization process, wherein the filling sequence of the data is that the data is filled from a stack start address, reading stack top data with a preset length of the stack space when the dead halt of the embedded system is detected, comparing the stack top data with the data in the specified format, and judging that the dead halt is caused by stack overflow if the stack top data are different. According to the scheme provided by the embodiment of the application, the data with the specified format can be filled in the stack space of the embedded system, so that after the system is halted, whether the cause of the halt is stack overflow can be judged by only checking whether the data with the specified format in the stack space changes or whether the variable initial value of the database changes, thereby realizing the rapid judgment of the cause of the halt and solving the problem of low diagnosis efficiency of the cause of the halt of the current embedded system.

Of course, it is not necessary for any one product or method of practicing the application to achieve all of the advantages set forth above at the same time.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the application, and other embodiments may be obtained according to these drawings to those skilled in the art.

FIG. 1 is a schematic flow chart of a method for diagnosing a crash of an embedded system according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a stack overflow dynamic detection according to an embodiment of the present application;

fig. 3 is a schematic flow chart of judging variable tampering according to an embodiment of the present application;

Fig. 4 is a schematic flow chart of variable tampering judgment provided in an embodiment of the present application;

FIG. 5 is a schematic flow chart of anomaly determination according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of anomaly determination according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a crash diagnosis system of an embedded system according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an intelligent door lock according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. Based on the embodiments of the present application, all other embodiments obtained by the person skilled in the art based on the present application are included in the scope of protection of the present application.

In a first aspect of the embodiment of the present application, referring to fig. 1, fig. 1 is a schematic flow diagram of a crash diagnosis method of an embedded system, where the method includes:

Step S11, in the initialization process, filling data in a specified format into a stack space of the embedded system, wherein the filling sequence of the data is that filling is started from a stack start address;

Step S12, when the embedded system is detected to be dead, reading stack top data with preset length of the stack space;

And S13, comparing the stack top data with the data in the specified format, and if the stack top data and the data in the specified format are different, judging that the crash cause is stack overflow.

Corresponding to the step S11, in the initializing process, the stack space of the embedded system may be filled with data in a specified format. The specified format can be set according to actual conditions, and is only required to be conveniently identified and compared, for example, the specified format can be 0xFFFFFFFF. In the embodiment of the present application, the data is filled from the stack start address, specifically, pointer operation in the C language may be used, filling may be performed from the stack bottom in units of bytes or words (according to the system architecture), and the length of the filled data may also be set. In the actual use process, after filling is completed, relevant information of stack space filling, such as filling mode, filling start time and the like, can be recorded, so that reference in the subsequent detection is facilitated.

Corresponding to the step S12, when the embedded system is detected to crash, the stack top data with the preset length of the stack space is read, specifically, when the system crashes and triggers, the position of the current stack top pointer can be obtained, then the current stack top pointer is read, the current stack top pointer is realized through reading a specific register or a memory position of the system, different embedded systems may have different acquisition modes, and then the stack top residual data is read from the position of the stack top pointer according to a certain byte number. The length of the certain number of bytes may be the same as the length of the data in the above-mentioned padding process, for example, may be 4 bytes, and may be specifically determined according to the data type of the padding mode.

Corresponding to the step S13, when comparing the stack top data with the data in the specified format, the read stack top residual data may be compared with the data in the pre-filled specified format. If the data are inconsistent, namely the data in the mode-specified format are destroyed, the stack overflow is judged, and if the data are consistent, the possibility of dead halt caused by the stack overflow can be eliminated.

In the actual use process, the stack is a memory space marked by the chip RAM (Random Access Memory ) and applied and released by the system. When a function is written, defined local variables, arrays, pointers, structures and the like are memory spaces applied for the variables only when a chip executes the function, after the function is executed, the memory is released by a system, the memory occupied by the applied variables belongs to stack space, stack space addresses grow from high to low, and a first-in last-out mode is adopted, so that stack bottom data change is caused when a stack overflows.

Therefore, by the scheme of the embodiment of the application, the stack space of the embedded system can be filled with the data in the appointed format, so that after the system is halted, whether the cause of the halt is stack overflow can be judged by only checking whether the data in the appointed format in the stack space is changed or whether the variable initial value of the database is changed, thereby realizing the rapid judgment of the cause of the halt and solving the problem of low diagnosis efficiency of the cause of the halt of the current embedded system.

In one possible implementation manner, the filling of the stack space of the embedded system with the data in the specified format comprises the steps of identifying the starting address and the size of the stack space of the embedded system, calculating the data quantity to be filled according to the size of the stack space, and filling the stack space with the data in the specified format according to the starting position of the stack space and the calculated data quantity to be filled. Specifically, the starting address and the size of the stack space of the embedded system are identified, and the starting address and the size of the stack space can be obtained by determining boundary information of the stack space through an interface function provided by the system or according to related specifications of a chip architecture and an operating system. According to the size of the stack space, the data quantity to be filled is calculated, and according to the size of the stack space, the data quantity to be filled can be calculated, wherein the data quantity to be filled is generally 4 bytes. According to the starting position of the stack space and the calculated data quantity to be filled, when filling the data with the specified format in the stack space, the growth direction (mostly from high to low) of the stack space address is considered, so that the filling sequence of the data in the application is to start filling from the stack starting address.

In one example, referring to fig. 2, stack overflow dynamic detection includes:

1. Initializing stack space filling mode 0xFFFFFFFF, and acquiring the initial address and size of stack space by calling related system functions according to the hardware configuration of a chip manual and a development board in the system initialization stage. For example, a main stack pointer (i.e., a top of stack address) is obtained using __ get_msp () function (a function used to obtain the value of the current main stack pointer), and the stack space boundaries are determined in conjunction with stack size information defined in the link script. And calculating the filling data amount according to the stack space size, and selecting to start filling from a stack start address as stack space addresses grow from high to low. The specific mode 0xFFFFFFFF is written into the stack space in sequence by using the circulation and pointer operation of the C language (a programming language) according to the unit of words, and after filling is completed, the filling mode and the filling starting time are recorded.

2. And when the system is halted, acquiring halt information to trigger a subsequent detection step.

3. And obtaining the current position of the pointer of the stack top by reading the get_MSP () function, and reading the stack top residual data with a certain byte length from the position.

4. Judging whether the mode value is destroyed, and comparing the stack top residual data with a pre-filled 0xFFFFFFFF mode. If the data is inconsistent, namely not destroyed, the stack is judged not to overflow, if the data is destroyed, the stack overflow is judged, and at the moment, the approximate time range of the occurrence of the stack overflow can be preliminarily judged according to the recorded information, so that clues are provided for subsequent analysis.

In a possible implementation manner, after the filling of the stack space of the embedded system with the data in the specified format in the initializing process, referring to fig. 3, fig. 3 is a schematic flow diagram of the judgment variable tampering provided in the embodiment of the present application, and the method further includes:

step S31, identifying a third party communication library address;

step S32, according to the identified address of the third party communication library, identifying the initial value of each variable in the third party communication library and mirroring;

step S33, identifying the current value of each variable in the third party communication library once every preset time;

and step S34, comparing the initial value of each variable with the current value of each variable, and if the initial value of each variable is different from the current value of each variable, judging that the variable is tampered.

Because the external code falsifies variable data of the third-party library at other positions to possibly cause a crash, the embodiment of the application can also identify the variable falsification to judge the cause of the crash. Specifically, the identification of the third party communication library address may generate a map file (an image data calling file) containing symbol information when compiling the embedded system program. And it may be required to ensure that the map file contains detailed address information of the third party library global variable, specifically, it may be ensured by compiler-related parameter settings. And then analyzing the map file, and locating the start address and the end address of the global variable of the third party library in the memory by searching a specific symbol table or text key word, thereby determining the address range. And then, storing the positioned address range information into a data structure, such as an array or a linked list, so as to facilitate quick access in subsequent operation, and checking the address range information to ensure the accuracy of the address range information. The deviation of subsequent monitoring caused by map file analysis errors can be avoided by comparing the map file analysis errors with documents of a third party library or known variable layout information. When the initial values of all variables in the third party communication library are identified according to the identified third party communication library address, a memory copy area which is completely consistent with the monitored variable can be opened up in a memory to serve as a mirror image storage area according to the located global variable address range of the third party communication library. Specifically, a memory allocation function (e.g., malloc (memory allocation, dynamic memory allocation) in the C language) may be used to apply for sufficient memory space, and then the initial value of the third party library global variable may be copied to the mirror storage area. Copying is performed byte by byte or variable by variable according to the address order of the variables, ensuring that the data of the mirrored memory is completely consistent with the original variable data.

And identifying the current value of each variable in the third party communication library once every preset time interval, wherein the current value can be identified by setting a periodic task. Specifically, a timer may be set for periodically triggering the comparison operation. In the actual use process, the comparison period can be reasonably set according to the system performance and the monitoring requirement, for example, every 100, 80 and 150 milliseconds is a period. And comparing the initial value of each variable with the current value of each variable, and comparing after periodically identifying the current value through the periodic task. In the timer interrupt service routine, the current value of the global variable of the third party library is compared with the data of the mirror image storage area. Recording a comparison result, if inconsistent variables are found, marking the variables and addresses thereof, and judging that the variables are tampered.

In one possible implementation, the comparison result comprises inconsistent variables and addresses, after comparing the initial values of the variables with the current values of the variables, the method further comprises identifying the current values of the variables corresponding to the monitoring points through monitoring points preset in codes, and comparing the current values of the variables corresponding to the monitoring points with historical values of the variables corresponding to the monitoring points to obtain tampered position information of the variables. In particular, business logic of the embedded system may be analyzed to determine key code segments that may be accessed or modified to third party library variables. For example, code regions involving third party library function calls, shared resource operations, and the like. And identifying the inconsistent variables and addresses through monitoring points preset in the codes, and corresponding positions, wherein the positions comprise corresponding functions or code lines. Wherein, the interception point can be inserted in the starting position and the ending position of the key code segment in advance. The snoop point may be implemented by inserting a specific function call or macro definition in the code that is used to record the data consistency check location marker. When the program is executed to the monitoring point, the value of the related variable of the current third party library is obtained, and the difference analysis is carried out between the value recorded by the last monitoring point and the value recorded by the last monitoring point. Specifically, a hash algorithm or a simple byte-by-byte comparison mode can be used to quickly locate the interval where the variable value changes. If abnormal change of the variable value in the key code segment is detected, combining with the function call stack information, further narrowing the falsification interval and trying to locate a specific function or code line.

In an example, referring to fig. 4, fig. 4 is a schematic flow chart of variable tampering determination provided in an embodiment of the present application, including:

1. And generating a map file containing symbol information by setting compiler parameters when compiling the project program, and ensuring that the map file contains detailed address information of a third party communication library global variable. And analyzing the map file by using an analysis tool or a custom script, searching the starting address and the ending address of the global variable of the third party communication library in the memory, determining the address range, and storing the address range into an array for convenient subsequent access. Meanwhile, the accuracy of the address range is checked compared with the document of the third party communication library.

2. Establishing a mirror image storage area, opening up a mirror image storage area consistent with the monitoring variable in the memory, applying for the memory space by using a malloc function, and copying the initial value of the global variable of the third party communication library to the mirror image storage area one by one.

3. Setting a timer, setting a trigger of a comparison operation every 100 milliseconds according to the system performance and the communication data change frequency. In the timer interrupt service routine, the current value of the global variable of the third party communication library is compared with the mirror image storage area data, and if inconsistent variables are found, the variables and the addresses thereof are marked.

4. And analyzing system business logic to determine key code segments related to the call of the third party communication library function and the data processing, such as the inside of data sending and receiving functions. At the beginning and end of these key code segments, snoop points are set by inserting macro definitions.

5. And when the program is executed to the monitoring point, acquiring the value of the related variable of the current third party communication library, and performing difference analysis on the value recorded by the last monitoring point by using a byte-by-byte comparison mode. If abnormal change of the variable value in the key code segment is detected, combining function call stack information, further positioning to specific functions and code lines, and determining possible positions of variable tampering.

In a possible implementation manner, after the filling of the stack space of the embedded system with the data in the specified format in the initializing process, referring to fig. 5, fig. 5 is a schematic flow diagram of anomaly determination provided by an embodiment of the present application, and the method further includes:

step S51, identifying pointers and sizes of allocated memory blocks in the embedded system;

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

step S53, obtaining the current pointer and the current size of each memory block once every preset time interval;

And step S54, comparing the current pointer and the size information with the pointer and the size recorded in the monitoring table, and judging whether the embedded system is abnormal or not.

Specifically, the pointer and the size of the allocated memory block in the embedded system may be identified by writing a function, for example, writing custom malloc and free functions (a dynamic memory release function), retaining original malloc and free functions in the custom functions, and adding a recording function. For example, default malloc and free function addresses of the system are saved using a function pointer for call in custom functions.

The identified pointers and sizes are recorded into the monitoring table, and when the memory allocation is successful, the allocated pointers and sizes can be recorded into the monitoring table in the custom malloc function. The monitoring table may be a structure array, and each element records information of memory allocation once. In the custom free function, when the memory is released, the corresponding allocation record is deleted from the monitor table. The current effective memory allocation information is always recorded in the monitoring table. In the actual use process, in order to ensure the accuracy and timeliness of the record, a mutual exclusion lock mechanism is added to the operation of the monitoring table. And the concurrent access to the monitoring table in the multi-thread or multi-task environment is prevented from causing data errors.

The current pointer and the current size of each memory block can be obtained once every preset time interval, a periodic checking task can be set, and the current pointer and the current size of each memory block can be realized by using a timer interrupt or task scheduling mechanism of the system. And the verification period is reasonably set according to the system performance and the memory service condition, for example, the verification is performed every 1 second. And traversing all memory allocation records in the monitoring table during each verification, and acquiring the pointer and the size information of each allocated memory block.

Comparing the current pointer and the current size information with the pointer and the current size recorded in the monitoring table to judge whether the embedded system is abnormal or not, and specifically, performing integrity check on the content of the dynamic memory according to the pointer and the current size of the memory block. The check of the memory block can be calculated and compared with the pre-stored check, or whether illegal data (such as access traces exceeding the allocation size) exists at the boundary of the memory block can be checked. If the integrity of the memory content is found to be abnormal, recording related information such as an abnormal memory block pointer, the size, the abnormal type and the like, and triggering a corresponding error processing mechanism such as printing an error log, sending an alarm signal and the like.

In an example, referring to fig. 6, fig. 6 is a schematic flow chart of anomaly determination provided in an embodiment of the present application, including:

1. And specifically, custom malloc and free functions can be written, and default malloc and free function addresses of the system are saved by using a function pointer in the custom functions so as to call the original function and add the recording function.

2. Recording the allocated pointer and the size to a monitoring table, recording the allocated pointer and the size to the monitoring table (defined as a structure array) after the memory allocation is successful in a custom malloc function, deleting the corresponding record from the monitoring table when the memory is released in a custom free function, and adding a mutual exclusion locking mechanism to prevent data errors in a multithreading environment.

3. And setting to execute periodic checking tasks every 1 second by using a timer interrupt mechanism of STM32 (a single chip microcomputer). And traversing the memory allocation record in the monitoring table during each verification to acquire the pointer and the size information of each memory block.

4. Detecting memory boundary crossing, checking the integrity of dynamic memory content by calculating CRC (cyclic redundancy check) check of memory blocks and comparing with pre-stored check sums or checking whether illegal data exists at the boundary of memory blocks.

5. If the integrity of the memory content is found to be abnormal, recording the information such as the pointer, the size, the abnormal type and the like of the abnormal memory block, triggering an error processing mechanism, printing an error log through a serial port, and facilitating the developer to find and process the problem in time.

According to the invention, the inventor researches and discovers that in the equipment project of the Internet of things, the diagnosis method and the diagnosis system are successfully utilized, and the problem of fast positioning to the dead halt is caused by stack overflow caused by overlarge local variable occupation stack space and memory boundary crossing in the dynamic memory allocation process when the third party communication library is used for high-concurrency data transmission, so that the system dead halt is caused. According to the positioning result, the developer optimizes the function call and memory allocation strategy, effectively solves the problem of dead halt, and improves the stability and reliability of the system.

In a second aspect of the embodiment of the present application, a crash diagnosis system of an embedded system is provided, referring to fig. 7, fig. 7 is a schematic structural diagram of the crash diagnosis system of an embedded system provided by the embodiment of the present application, where the system includes:

the data filling module 701 is configured to fill data in a specified format into a stack space of the embedded system in an initialization process, where the filling sequence of the data is that the data starts to be filled from a stack start address;

The data reading module 702 is configured to read stack top data with a preset length of the stack space when the embedded system is detected to be dead;

And the reason judging module 703 is configured to compare the stack top data with the data in the specified format, and if the stack top data and the data in the specified format are different, judge that the crash reason is stack overflow.

In one possible embodiment, the system further comprises:

The embodiment of the application also provides an intelligent door lock, as shown in fig. 8, comprising:

a memory 801 for storing a computer program;

the processor 802 is configured to execute the program stored in the memory 801, and implement the following steps:

The communication bus mentioned by the above-mentioned intelligent door lock may be a peripheral component interconnect standard (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, etc. The communication bus may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus.

The communication interface is used for communication between the intelligent door lock and other equipment.

The Memory may include random access Memory (Random Access Memory, RAM) or may include Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the aforementioned processor.

The Processor may be a general-purpose Processor including a central processing unit (Central Processing Unit, CPU), a network Processor (Network Processor, NP), etc., or may be a digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), field-Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic device, discrete gate or transistor logic device, discrete hardware components.

In yet another embodiment of the present application, there is also provided a computer readable storage medium having stored therein a computer program which when executed by a processor implements the steps of any of the methods described above.

In yet another embodiment of the present application, there is also provided a computer program product containing instructions which, when run on a computer, cause the computer to perform any of the methods of the above embodiments.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may 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 loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a Solid state disk (Solid STATE DISK, SSD), etc.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises an element.

In this specification, each embodiment is described in a related manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for the system, smart door lock, storage medium embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and references to the parts of the description of the method embodiments are only needed.

The foregoing description is only of the preferred embodiments of the present application and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A method for crash diagnosis of an embedded system, the method comprising:

2. The method of claim 1, wherein the populating the stack space of the embedded system with data in a specified format comprises:

3. The method of claim 1, wherein after filling the stack space of the embedded system with data in a specified format during the initializing, the method further comprises:

identifying a third party communication library address;

4. A method according to claim 3, wherein the comparison result comprises an inconsistent variable and an address;

5. The method of claim 1, wherein after filling the stack space of the embedded system with data in a specified format during the initializing, the method further comprises:

Recording the identified pointer and size into a monitoring table;

6. A crash diagnostic system for an embedded system, the system comprising:

7. The system of claim 6, wherein the system further comprises a controller configured to control the controller,

The reason judging module is specifically used for identifying the starting address and the size of the stack space of the embedded system, calculating the data quantity to be filled according to the size of the stack space, and filling the data with the appointed format according to the starting position of the stack space and the calculated data quantity to be filled.

8. The system of claim 6, wherein the system further comprises:

The system comprises a tamper identification module, a tamper detection module and a tamper detection module, wherein the tamper detection module is used for identifying a third party communication library address, identifying initial values of variables in the third party communication library according to the identified third party communication library address, identifying current values of the variables in the third party communication library once every preset time, mirroring the current values of the variables, comparing the initial values of the variables with the current values of the variables, and judging whether the variables are tampered according to comparison results.

9. An intelligent door lock, characterized by comprising:

a memory for storing a computer program;

A processor for implementing the method of any of claims 1-5 when executing a program stored on a memory.

10. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program which, when executed by a processor, implements the method of any of claims 1-5.