WO2013008326A1 - Procédé de vérification de logiciel et système de vérification de logiciel - Google Patents

Procédé de vérification de logiciel et système de vérification de logiciel Download PDF

Info

Publication number
WO2013008326A1
WO2013008326A1 PCT/JP2011/066012 JP2011066012W WO2013008326A1 WO 2013008326 A1 WO2013008326 A1 WO 2013008326A1 JP 2011066012 W JP2011066012 W JP 2011066012W WO 2013008326 A1 WO2013008326 A1 WO 2013008326A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
application
software verification
target application
verification target
Prior art date
Application number
PCT/JP2011/066012
Other languages
English (en)
Japanese (ja)
Inventor
浩一郎 山下
宏真 山内
鈴木　貴久
康志 栗原
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2011/066012 priority Critical patent/WO2013008326A1/fr
Publication of WO2013008326A1 publication Critical patent/WO2013008326A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software

Definitions

  • the present invention relates to a software verification method and a software verification system for verifying software.
  • multi-core environment a multi-core processor system environment
  • a thread is an execution unit of a program.
  • single-core environment When a software that was operating in a single-core processor system environment (hereinafter referred to as “single-core environment”) is operated in a multi-core environment, side effects associated with parallelization have occurred. For example, a side effect that a potential failure due to a change in operation timing becomes noticeable has occurred. Also, for software newly developed for a multi-core environment, it has been more difficult to verify all the operation timings than in a single-core environment.
  • a technique for acquiring software trace information by setting a breakpoint is disclosed. Also disclosed is a technique for executing single-core environment software and multi-core environment software and comparing runtime data. Further, as a technique for operating a plurality of environments, a technique for executing a plurality of environments on a virtual machine that virtualizes computer resources and comparing execution results of software executed on the plurality of environments is disclosed. (For example, see Patent Documents 1 to 3 below.)
  • the present invention has an object to provide a software verification method and a software verification system that facilitate software verification in a multi-core environment in order to solve the above-described problems caused by the prior art.
  • a virtual machine secures a context area based on the activation of an application in the first operating system and context in the second operating system.
  • the area information is notified, the context area data is saved in the save area based on the application state change, and the execution of the application is switched from the first operating system to the second operating system, which is executed by the second operating system.
  • a software verification method and a software verification system for comparing a context area and a save area based on a change in the state of an application are proposed.
  • FIG. 1 is an explanatory diagram illustrating an operation example of the multi-core processor system 100.
  • FIG. 2 is a block diagram illustrating a hardware example of the multi-core processor system 100.
  • FIG. 3 is a block diagram illustrating an example of functions of the multi-core processor system 100.
  • FIG. 4 is an explanatory diagram illustrating an example of a state during the operation of the single OS 113.
  • FIG. 5 is an explanatory diagram illustrating an example of a state during the operation of the multi-OS 114.
  • FIG. 6 is a flowchart illustrating an example of a processing procedure when the single OS 113 and the multi-OS 114 are activated.
  • FIG. 7 is a flowchart illustrating an example of a processing procedure when the verification target application 115 is activated.
  • FIG. 1 is an explanatory diagram illustrating an operation example of the multi-core processor system 100.
  • FIG. 2 is a block diagram illustrating a hardware example of the multi-core processor system 100.
  • FIG. 8 is a flowchart (part 1) illustrating an example of a processing procedure during verification of the verification target application 115.
  • FIG. 9 is a flowchart (part 2) illustrating an example of a processing procedure during verification of the verification target application 115.
  • FIG. 10 is an explanatory diagram illustrating an application example of a system using a computer according to the present embodiment.
  • a multi-core processor is a processor having a plurality of cores. If a plurality of cores are mounted, a single processor having a plurality of cores may be used, or a processor group in which single core processors are arranged in parallel may be used. In the present embodiment, in order to simplify the explanation, a processor group in which single core processors are arranged in parallel will be described as an example.
  • FIG. 1 is an explanatory diagram showing an operation example of the multi-core processor system 100.
  • the multi-core processor system 100 includes CPU # 0 to CPU # 3 and a shared memory 112.
  • a debugger VM virtual machine
  • OS operating system: Operating System
  • multi-OS multi-OS
  • the debugger VM 111 is a virtual machine that virtualizes computer resources and further has a debugger function. Specifically, the debugger VM 111 controls the single OS 113 and the multi OS 114 that operate on the debugger VM 111, and switches the execution OS from the single OS 113 to the multi OS 114 or from the multi OS 114 to the single OS 113. Further, the debugger VM 111 may perform memory dump, stack trace, and the like as a debugger function.
  • the shared memory 112 is a memory accessed from the CPU # 0 to CPU # 3.
  • the single OS 113 is an OS that operates on one CPU
  • the multi-OS 114 is an OS that operates on a plurality of CPUs.
  • FIG. 1 shows a state 101 and a state 102 as the operating environment of the multi-core processor system 100.
  • the multi-core processor system 100 in the state 101 is in a state where it is in a single core environment in which the single OS 113 is executed as the execution OS.
  • the multi-core processor system 100 in the state 102 is a state in which the multi-core processor system 100 is in a multi-core environment in which the multi-OS 114 is executed.
  • verification target application 115_S and verification target application 115_M which are application software (hereinafter referred to as “applications”), are verified as software to be verified. It is assumed that the verification target application 115_S and the verification target application 115_M are generated from the source code 116.
  • the verification target application 115_S is an application executed in a single core environment
  • the verification target application 115_M is an application executed in a multicore environment.
  • the verification target application 115_S and the verification target application 115_M may be the same object code or may be different.
  • the source code 116 describes that the synchronization wait process is executed inside the argumentless return value int type main function.
  • the verification target application 115_S and the verification target application 115_M are generated from the same source code 116, they may be different.
  • the verification target application 115_M may be an object code generated from a source code in which a code corresponding to a multi-core environment is added to the source code of the verification target application 115_S.
  • the multi-core processor system 100 secures the verification target application context area 121 and the save area 122.
  • the verification target application context area 121 is a context area used by software to be verified.
  • the context area is an area for storing data used by the application such as a CPU register value, a program counter, and a stack pointer.
  • the CPU # 0 executes the verification target application 115_S and has reached the synchronization waiting process which is one of the state changes of the verification target application 115_S.
  • the CPU # 0 writes the single core environment section data 123, which is the execution result of the verification target application 115_S, in the verification target application context area 121.
  • the debugger VM 111 that has received the status change of the verification target application 115_S switches the execution OS from the single OS 113 to the multi OS 114. At this time, the debugger VM 111 saves the single core environment section data 123 in the save area 122.
  • the CPUs # 0 to # 3 execute the verification target application 115_M, and have reached the synchronization waiting process which is one of the state changes of the verification target application 115_M.
  • the CPUs # 0 to # 3 write the multi-core environment section data 124, which is the execution result of the verification target application 115_M, in the verification target application context area 121.
  • the debugger VM 111 that has received the state change of the verification target application 115_M compares the single-core environment section data 123 with the multi-core environment section data 124.
  • the multi-core processor system 100 executes the verification target application in the single-core environment and the multi-core environment, and compares the write data of the two applications when the state of the application changes. Thereby, the multi-core processor system 100 does not need to trace all steps, and facilitates application verification in a multi-core environment.
  • FIG. 2 is a block diagram illustrating a hardware example of the multi-core processor system 100.
  • Multi-core processor system 100 in the present embodiment assumes a mobile terminal such as a mobile phone.
  • the multi-core processor system 100 includes CPUs 201, ROM (Read-Only Memory) 202, and RAM (Random Access Memory) 203.
  • the multi-core processor system 100 includes a flash ROM 204, a flash ROM controller 205, and a flash ROM 206. Further, the multi-core processor system 100 includes a display 207, an I / F (Interface) 208, and a keyboard 209 as input / output devices for a user and other devices. Each unit is connected by a bus 210. Note that specific devices of the shared memory 112 are a RAM 203 and a flash ROM 204. Of the data stored in the shared memory 112, data that is not written may be stored in the ROM 202.
  • the CPUs 201 control the entire multi-core processor system 100.
  • the CPUs 201 include CPU # 0 to CPU # 3.
  • the CPUs 201 may have a dedicated cache memory.
  • the ROM 202 stores programs such as a boot program.
  • the RAM 203 is used as a work area for the CPUs 201.
  • the flash ROM 204 is a flash ROM having a high reading speed, and is, for example, a NOR flash memory.
  • the flash ROM 204 stores system software such as an OS, application software, and the like.
  • the multi-core processor system 100 receives the new OS by the I / F 208 and updates the old OS stored in the flash ROM 204 to the received new OS.
  • the flash ROM controller 205 controls reading / writing of data with respect to the flash ROM 206 according to the control of the CPUs 201.
  • the flash ROM 206 is a flash ROM mainly for storing and transporting data, and is, for example, a NAND flash memory.
  • the flash ROM 206 stores data written under the control of the flash ROM controller 205. Specific examples of the data include image data and video data acquired by the user using the multi-core processor system 100 through the I / F 208, and a program for executing the software verification method according to the present embodiment.
  • the flash ROM 206 for example, a memory card, an SD card, or the like can be adopted.
  • the display 207 displays data such as a cursor, an icon or a tool box, a document, an image, and function information.
  • a TFT (Thin Film Transistor) liquid crystal display can be adopted.
  • the I / F 208 is connected to a network 211 such as a LAN, a WAN (Wide Area Network), and the Internet through a communication line, and is connected to another device via the network 211.
  • the I / F 208 controls an internal interface with the network 211 and controls input / output of data from an external device.
  • a modem or a LAN adapter can be adopted as the I / F 208.
  • the keyboard 209 has keys for inputting numbers and various instructions, and inputs data.
  • the keyboard 209 may be a touch panel type input pad or a numeric keypad.
  • FIG. 3 is a block diagram illustrating an example of functions of the multi-core processor system 100.
  • the multi-core processor system 100 includes a securing unit 301, a notification unit 302, a reception unit 303, a comparison unit 304, a switching unit 305, a switching unit 306, and an output unit 307.
  • the functions (securing unit 301 to output unit 307) serving as the control unit are realized by the CPUs 201 executing the program stored in the storage device.
  • the storage device is, for example, the ROM 202, the RAM 203, the flash ROM 204, the flash ROM 206, etc. shown in FIG.
  • the securing unit 301 to the output unit 307 are included in the function of the debugger VM 111.
  • the multi-core processor system 100 secures a user space 310.
  • the user space 310 is a space for securing an application context area.
  • the CPU # 0 executes the single OS 113.
  • the CPU # 0 executes the kernel 311 # 0
  • the CPU # 1 executes the kernel 311 # 1
  • the CPU # 2 executes the kernel 311 # 2.
  • CPU # 3 executes kernel 311 # 3.
  • the kernel 311 is software having a function that forms the core of the multi-OS 114.
  • the securing unit 301 has a function of securing a user space 310 shared by the first operating system and the second operating system.
  • the first operating system is a single OS 113
  • the second operating system is a multi-OS 114.
  • the securing unit 301 instructs the multi-OS 114 to share the user space 310.
  • the securing unit 301 may instruct the single OS 113 to share the user space 310 secured by the multi-OS 114.
  • the securing unit 301 secures the save area 122 from the shared memory 112.
  • the save area 122 is secured from an unallocated space other than the user space 310.
  • the save area 122 may be an area of 8, 16 [K bytes].
  • the upper limit and lower limit address of the reserved user space 310 and the upper limit and lower limit address of the save area 122 are stored in a storage area such as the RAM 203 and the flash ROM 204.
  • the notification unit 302 has a function of securing a context area based on the activation of the application in the first operating system and notifying the second operating system of the context area information. For example, the notification unit 302 notifies the multi-OS 114 of the verification target application context area 121 secured in response to activation by the verification target application 115_S in the single OS 113.
  • the accepting unit 303 has a function of accepting a change in the state of an application executed by the first and second operating systems.
  • the reception unit 303 receives a state change of the verification target application 115_S from the single OS 113 and receives a state change of the verification target application 115_M from the multi-OS 114.
  • the specific state change is the start of exclusive control processing, synchronization waiting processing, branch processing, or error processing. Details of each process will be described later with reference to FIG. Further, the identification information of the single OS 113 or the multi-OS 114 as the reception source OS and the type of the received state change are stored in a storage area such as the RAM 203 and the flash ROM 204.
  • the comparison unit 304 has a function of comparing the context area and the save area 122 based on the state change of the application executed in the second operating system. For example, when there is a change in the state of the verification target application 115_M executed by the multi-OS 114, the comparison unit 304 determines that the multicore environment section data 124 in the verification target application context area 121 and the single core environment section data 123 in the save area 122 And compare. Note that the comparison result is stored in a storage area such as the RAM 203 and the flash ROM 204.
  • the exchange unit 305 has a function of exchanging data in the context area and data in the save area 122. For example, the exchange unit 305 exchanges the multi-core environment section data 124 in the verification target application context area 121 and the single-core environment section data 123 in the save area 122. When the verification target application 115 is executed only on one OS, the exchange unit 305 only needs to save the data in the verification target application context area 121 to the save area 122.
  • the switching unit 306 has a function of switching the execution of the application from the first operating system to the second operating system.
  • the switching unit 306 switches the execution of the application from the second operating system to the first operating system when the comparison result by the comparing unit 304 indicates a match. For example, when the single core environment section data 123 and the multicore environment section data 124 match, the switching unit 306 switches from the multi OS 114 to the single OS 113.
  • the switching unit 306 executes the application when the comparison result by the comparison unit 304 indicates a mismatch and the state change of the verification target application 115 is the start of other processing other than the error processing.
  • the switching unit 306 Switch to single OS 113.
  • the output unit 307 has a function of outputting an alert when the comparison result by the comparison unit 304 indicates a mismatch. For example, the output unit 307 outputs an alert when the single-core environment section data 123 and the multi-core environment section data 124 do not match.
  • the content of the alert that is output includes, for example, the address of the code that called the state change process, the type of state change, and the single core environment section data 123 and multicore environment section data 124 that did not match. Memory dump etc.
  • the output unit 307 may output information on error processing when the result of the comparison by the comparison unit 304 indicates inconsistency and the application state change is the start of error processing.
  • error processing information include error causes of error processing, addresses of codes that are called to perform state changes, memory dumps of mismatched single core environment section data 123 and multicore environment section data 124, and the like. It is.
  • the output unit 307 outputs SIGBUS (SIGnal BUS error) indicating a bus error and SIGEGV (SIGnal SEGmentation Violation) indicating that an invalid address has been accessed as a signal number that is a specific error factor.
  • SIGBUS SIGnal BUS error
  • SIGEGV SIGnal SEGmentation Violation
  • the state of the single-core environment of the multi-core processor system 100 and the state of the multi-core environment will be described with reference to FIGS.
  • the verification target application 115_S is first executed in the single core environment, and then the verification target application 115_M is executed in the multicore environment.
  • the multi-core processor system 100 may first execute the verification target application 115_M in the multi-core environment and then execute the verification target application 115_S.
  • FIG. 4 is an explanatory diagram showing an example of a state during the operation of the single OS 113.
  • the state of the multi-core processor system 100 shown in FIG. CPU # 0 executes the single OS 113, and CPU # 1 to CPU # 3 are inactive.
  • the debugger VM 111 secures the user space 310 and the save area 122 in the shared memory 112 when the single OS 113 and the multi-OS 114 are booted.
  • the debugger VM 111 receives a notification of a state change from the single OS 113.
  • the details of the state change are the start of exclusive control processing, synchronization waiting processing, branch processing, and error processing as shown in the state change list 401.
  • the single OS 113 detects the start of the exclusive control process, the synchronization wait process, the branch process, and the error process, the single OS 113 notifies the debugger VM 111 as a state change.
  • Exclusive control processing is processing in which when one thread acquires the right to use a resource or the like, the other thread waits until one thread releases the right to use the resource.
  • the synchronization waiting process is a process for temporarily stopping processing of a plurality of threads up to a specific code position. When all the threads have reached a specific code position, the synchronization waiting process releases the stop and continues the next process.
  • the single OS 113 can detect that the exclusive control process is performed on the verification target application 115_S by calling a system call that performs the exclusive control process and the synchronization waiting process.
  • Branch processing is processing that branches a thread. For example, there are a fork function and a CreateThread function as branch processing.
  • the single OS 113 can detect that the branch process is performed on the verification target application 115_S by calling a system call that performs the branch process.
  • the error process is a process for notifying an error that has occurred in the program. For example, when an error occurs, the single OS 113 can detect that error processing is performed when an error interrupt is executed.
  • the debugger VM 111 When the debugger VM 111 receives the state change shown in the state change list 401, the debugger VM 111 exchanges the single core environment section data 123 and the multicore environment section data 124. Specifically, the debugger VM 111 saves the single core environment section data 123 in the save area 122. Further, the debugger VM 111 writes back the multi-core environment section data 124 existing in the save area 122 to the verification target application context area 121.
  • FIG. 5 is an explanatory diagram showing an example of a state during the multi-OS 114 operation.
  • the multi-core processor system 100 shown in FIG. CPU # 0 executes kernel 311 # 0, CPU # 1 executes kernel 311 # 1, CPU # 2 executes kernel 311 # 2, and CPU # 3 executes kernel 311 # 3.
  • the comparison unit 304 compares the single-core environment section data 123 with the multi-core environment section data 124. When the comparison results match, the debugger VM 111 switches from the multi-OS 114 to the single OS 113. If the comparison result does not match, the debugger VM 111 outputs an alert when the state change is not error processing, exchanges the single core environment section data 123 and the multicore environment section data 124, and switches from the multi OS 114 to the single OS 113. When the state change is error processing, the debugger VM 111 outputs information related to error processing and stops the verification target application 115_M.
  • FIG. 6 illustrates processing when the single OS 113 and the multi-OS 114 are started
  • FIG. 7 illustrates processing when the verification target application 115 is started
  • FIG. 8 illustrates processing in the single OS 113 during verification of the verification target application 115
  • FIG. 9 illustrates processing in the multi-OS 114 during verification of the verification target application 115.
  • FIG. 6 is a flowchart showing an example of a processing procedure when the single OS 113 and the multi-OS 114 are activated.
  • the debugger VM 111 boots the multi-OS 114 (step S601).
  • the debugger VM 111 waits until receiving a notification from the multi-OS 114.
  • the multi-OS 114 secures the user space 310 (step S602), notifies the secured user space 310 to the debugger VM 111 (step S603), and ends the process at the time of startup.
  • the debugger VM 111 that has received the notification defines the user space 310 as a shared space (step S604). Subsequently, the debugger VM 111 boots the single OS 113 (step S605). At this time, the debugger VM 111 notifies the single OS 113 of the defined shared space. Further, the debugger VM 111 waits until a notification is received from the single OS 113. The single OS 113 secures the shared space as the user space 310 (step S606), notifies the secured user space 310 to the debugger VM 111 (step S607), and ends the processing at the time of startup. The debugger VM 111 that has received the notification secures the save area 122 from the unallocated space (step S608), and ends the processing at the time of activation.
  • the single OS 113 and the multi-OS 114 have secured their own kernel space in the processing of step S602 and step S606.
  • the kernel space is an area of about 1 [M bytes], and is narrower than the user space 310.
  • FIG. 7 is a flowchart illustrating an example of a processing procedure when the verification target application 115 is activated.
  • the verification target application 115_S is first activated by the single OS 113 and then the verification target application 115_M is activated by the multi-OS 114. However, after the verification target application 115_M is first activated, 115_S may be activated.
  • the single OS 113 activates the verification target application 115_S (step S701), notifies the debugger VM 111 of the activation of the verification target application 115_S (step S702), and ends the processing when the verification target application 115 is activated.
  • the debugger VM 111 that has received the notification stores the verification target application context area 121 (step S703). As specific save contents, the debugger VM 111 saves the lower limit address and the upper limit address of the verification target application context area 121. Subsequently, the debugger VM 111 notifies the multi-OS 114 of a context area sharing instruction (step S704). Specifically, the debugger VM 111 notifies the multi-OS 114 of the address of the verification target application context area 121. After the notification, the debugger VM 111 ends the process when starting the verification target application 115.
  • the multi-OS 114 that has received the notification activates the verification target application 115_M using the verification target application context area 121 (step S705), and ends the processing when the verification target application 115 is started.
  • FIG. 8 is a flowchart (part 1) illustrating an example of a processing procedure during verification of the verification target application 115.
  • the verification target application 115_S continues to perform normal execution (step S801).
  • the single OS 113 detects a change in state performed during normal execution.
  • the verification target application 115_S is executed when the execution OS becomes the single OS 113.
  • the case where the execution OS becomes the single OS 113 is, for example, when the verification target application 115_S is activated or when the execution OS is switched from the multi-OS 114 to the single OS 113 in step S912 described later.
  • the single OS 113 determines whether or not a state change of the verification target application 115_S has been detected (step S802).
  • step S802: Yes the single OS 113 notifies the debugger VM 111 of the state change (step S803), and the process proceeds to step S802.
  • step S802: No the single OS 113 executes the process of step S802 again after a predetermined time has elapsed.
  • the debugger VM 111 receives the notification (step S804). Next, the debugger VM 111 exchanges the single-core environment section data 123 in the verification target application context area 121 and the multi-core environment section data 124 in the save area 122 (step S805). Subsequently, the debugger VM 111 switches the execution OS from the single OS 113 to the multi OS 114 (step S806), and ends the process during verification of the verification target application 115.
  • FIG. 9 is a flowchart (part 2) illustrating an example of a processing procedure during verification of the verification target application 115.
  • the verification target application 115_M continues to perform normal execution (step S901).
  • a state change made during normal execution is detected by the multi-OS 114.
  • the verification target application 115_M is executed when the execution OS becomes the multi-OS 114.
  • the case where the execution OS becomes the multi-OS 114 is, for example, the case where the execution OS is switched from the single OS 113 to the multi-OS 114 in step S806.
  • the multi-OS 114 determines whether or not a state change of the verification target application 115_M is detected (step S902). When the state change is detected (step S902: Yes), the multi-OS 114 notifies the debugger VM 111 of the state change (step S903), and the process proceeds to step S902. When the state change is not detected (step S902: No), the multi-OS 114 executes the process of step S902 again after a predetermined time has elapsed.
  • the debugger VM 111 receives the notification (step S904).
  • the debugger VM 111 compares the multi-core environment section data 124 in the verification target application context area 121 with the single-core environment section data 123 in the save area 122 (step S905). Subsequently, the debugger VM 111 determines whether or not the comparison result indicates a match (step S906). If the comparison result indicates a mismatch (step S906: No), the debugger VM 111 continues to determine whether or not the state change is the start of error processing (step S907).
  • step S907 If it is the start of error processing (step S907: Yes), the debugger VM 111 outputs information related to error processing (step S908), stops the verification target application 115_M (step S909), and is verifying the verification target application 115. The process ends.
  • step S910 the debugger VM 111 outputs an alert (step S910). After outputting the alert, the debugger VM 111 exchanges the multi-core environment section data 124 in the verification target application context area 121 and the single-core environment section data 123 in the save area 122 (step S911). After the replacement or when the comparison result indicates a match (step S906: Yes), the debugger VM 111 switches the execution OS from the multi-OS 114 to the single OS 113 (step S912), and ends the process during verification of the verification target application 115. To do.
  • the execution position of the verification target application in the single core environment may be different from the execution position of the verification target application in the multicore environment.
  • the verification target application 115_S or the verification target application 115_M is terminated first. If one of the verification target applications 115 has ended after switching from the switching source OS to the switching destination OS in the processing of step S806 and step S912, the debugger VM 111 switches to the switching source OS again and has not ended.
  • the verification target application 115 is executed.
  • FIG. 10 is an explanatory diagram showing an application example of a system using a computer according to the present embodiment.
  • a network NW is a network in which a server 1001, a server 1002, and clients 1031 to 1034 can communicate, and includes, for example, a LAN, a WAN, the Internet, a mobile phone network, and the like.
  • the server 1002 is a management server of a server group (server 1021 to server 1025) having the cloud 1020.
  • the client 1031 is a notebook PC (Personal Computer).
  • the client 1032 is a desktop PC, and the client 1033 is a mobile phone.
  • the client 1033 may be a smartphone or a PHS (Personal Handyphone System).
  • the client 1034 is a tablet terminal.
  • the server 1001, the server 1002, the server 1021 to the server 1025, and the client 1031 to the client 1034 in FIG. 10 execute the software verification method according to the present embodiment.
  • the CPU of the server 1021 executes the single OS 113
  • the CPU group of the servers 1021 to 1025 executes the multi-OS 114
  • the application is executed in the single-core environment and the multi-core environment, and the write data of the two applications is compared when the state of the application changes. Since a failure in the multi-core environment occurs due to a state change, the software verification system does not need to trace all the steps, and can easily perform application verification in the multi-core environment. In addition, the software verification system can perform verification with one board without performing debugging with two boards by switching a plurality of environments using a VM.
  • the software verification system may share the context area of the verification target application in two environments. Thereby, the software verification system can reduce the amount of memory used.
  • the software verification system may switch from the multi-core environment to the single-core environment when the comparison between the context area and the save area indicates a match. Since the comparison indicates a match and the multi-core environment is operating normally, the software verification system can continue the operation of the verification target application.
  • the software verification system may write the data in the save area back to the context area.
  • the software verification system executes the verification target application in the single core environment, so that the software verification system can verify the verification target application in the single core environment. Can continue operation.
  • the software verification system may output an alert when the comparison result indicates a mismatch.
  • the software verification system can record an intermediate calculation result at the time of a state change, and when the memory destruction occurs later, it becomes easy to trace the data that caused the memory destruction.
  • the state change may include the start of at least one of an exclusive control process, a synchronization wait process, a branch process, or an error process.
  • Problems that occur in a multi-core environment occur by executing exclusive control processing, synchronization wait processing, and branch processing. Therefore, the software verification system causes data corruption by comparing data at the start of each processing. Can be obtained with certainty.
  • the software verification system may switch from the multi-core environment to the single-core environment while outputting an alert when the comparison result indicates a mismatch and the state change is other processing other than error processing.
  • the execution position of the verification target application in the single-core environment may be different from the execution position of the verification target application in the multi-core environment. Examples of different cases include branch processing between asynchronous threads.
  • the software verification system Since the status change accepted when the execution position is shifted is another process other than the error process, the software verification system outputs an alert and continues verification of the verification target application.
  • the deviation of the execution position is resolved by the end of the thread in the verification target application or the join function. If the result of the comparison shows a match when the deviation is resolved, the software verification system uses the judgment material that the alert that has been output so far has been output as the result of the deviation and that it was not output due to a malfunction. Can be presented.
  • the software verification system may stop the verification target application while outputting information related to error processing when the comparison result indicates a mismatch and the state change is error processing.
  • the software verification system can indicate which state change caused a memory mismatch by the alert log that has been output.
  • the OS executed by the software verification system may be a single-core compatible OS or a multi-core compatible OS.
  • the OS to be executed is multi-core compatible and may be an OS group having a different number of cores.
  • the OS executed by the software verification system may be a 2-core-compatible OS and a 3-core-compatible OS.
  • the software verification method described in the present embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation.
  • the program for executing the software verification method is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer.
  • the program for executing this software verification method may be distributed through a network such as the Internet.
  • Multi-core processor system 111 Debugger VM 112 Shared memory 113 Single OS 114 Multi-OS 115_S, 115_M Verification target application 121 Verification target application context area 122 Save area 123 Single-core environment section data 124 Multi-core environment section data 301 Reservation section 302 Notification section 303 Reception section 304 Comparison section 305 Exchange section 306 Switching section 307 Output section 310 User space 311 kernel

Abstract

La présente invention facilite la vérification d'un logiciel dans un environnement multicœur. Un système de processeur multicœur (100) exécute un système d'exploitation (OS) unique (113) dans un état (101). Lors de la réception d'un changement d'état d'une application à vérifier (115_S) qui est en cours d'exécution sur l'OS unique (113), une machine virtuelle (VM) de débogage (111) commute l'OS exécuté de l'OS unique (113) à un OS multiple (114). Subséquemment, lors de la réception d'un changement d'état de l'application à vérifier (115_M) qui est en cours d'exécution sur l'OS multiple (114), la VM de débogage (111) compare des données de section d'environnement multicœur (124) à des données de section d'environnement monocœur (123).
PCT/JP2011/066012 2011-07-13 2011-07-13 Procédé de vérification de logiciel et système de vérification de logiciel WO2013008326A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/066012 WO2013008326A1 (fr) 2011-07-13 2011-07-13 Procédé de vérification de logiciel et système de vérification de logiciel

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/066012 WO2013008326A1 (fr) 2011-07-13 2011-07-13 Procédé de vérification de logiciel et système de vérification de logiciel

Publications (1)

Publication Number Publication Date
WO2013008326A1 true WO2013008326A1 (fr) 2013-01-17

Family

ID=47505645

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/066012 WO2013008326A1 (fr) 2011-07-13 2011-07-13 Procédé de vérification de logiciel et système de vérification de logiciel

Country Status (1)

Country Link
WO (1) WO2013008326A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106484620A (zh) * 2016-10-12 2017-03-08 北京元心科技有限公司 对多系统终端设备执行测试的方法、控制设备及控制台
CN107688532A (zh) * 2017-07-12 2018-02-13 郑州云海信息技术有限公司 实现Linux到Dos测试平台自动切换的方法、系统及辅助服务器
JPWO2021070393A1 (fr) * 2019-10-11 2021-04-15
US20230161598A1 (en) * 2021-11-25 2023-05-25 Wiwynn Corporation System booting method and related computer system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07271631A (ja) * 1994-03-31 1995-10-20 Fujitsu Ltd デバッガ
JPH08137714A (ja) * 1994-09-12 1996-05-31 Nec Corp マルチタスクプログラムのデバッグ方法およびデバッグシステム
JP2006522968A (ja) * 2003-03-25 2006-10-05 ギーゼッケ　ウント　デフリエント　ゲーエムベーハー 携帯型データ・キャリアのバーチャル・マシン向けプログラムの制御実行
WO2009147738A1 (fr) * 2008-06-05 2009-12-10 富士通株式会社 Processeur d’informations, procede de commande et programme moniteur associes
JP2011028438A (ja) * 2009-07-23 2011-02-10 Alpine Electronics Inc アプリケーション検証システム及びコンピュータプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07271631A (ja) * 1994-03-31 1995-10-20 Fujitsu Ltd デバッガ
JPH08137714A (ja) * 1994-09-12 1996-05-31 Nec Corp マルチタスクプログラムのデバッグ方法およびデバッグシステム
JP2006522968A (ja) * 2003-03-25 2006-10-05 ギーゼッケ　ウント　デフリエント　ゲーエムベーハー 携帯型データ・キャリアのバーチャル・マシン向けプログラムの制御実行
WO2009147738A1 (fr) * 2008-06-05 2009-12-10 富士通株式会社 Processeur d’informations, procede de commande et programme moniteur associes
JP2011028438A (ja) * 2009-07-23 2011-02-10 Alpine Electronics Inc アプリケーション検証システム及びコンピュータプログラム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106484620A (zh) * 2016-10-12 2017-03-08 北京元心科技有限公司 对多系统终端设备执行测试的方法、控制设备及控制台
CN106484620B (zh) * 2016-10-12 2019-06-18 北京元心科技有限公司 对多系统终端设备执行测试的方法、控制设备及控制台
CN107688532A (zh) * 2017-07-12 2018-02-13 郑州云海信息技术有限公司 实现Linux到Dos测试平台自动切换的方法、系统及辅助服务器
JPWO2021070393A1 (fr) * 2019-10-11 2021-04-15
JP7287480B2 (ja) 2019-10-11 2023-06-06 日本電信電話株式会社 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
US20230161598A1 (en) * 2021-11-25 2023-05-25 Wiwynn Corporation System booting method and related computer system

Similar Documents

Publication Publication Date Title
TWI639084B (zh) 管理與經選擇架構設施相關聯之處理
US9870248B2 (en) Page table based dirty page tracking
US20130227551A1 (en) System and method for hypervisor version migration
US20110113426A1 (en) Apparatuses for switching the running of a virtual machine between multiple computer devices belonging to the same computer platform and the associated switching methods
TW201602806A (zh) 架構模式組態
TW201610708A (zh) 用於可在多種架構中初始化之控制公用程式之共同開機順序
US8943284B2 (en) Systems and methods for integrating compute resources in a storage area network
US8813069B2 (en) Migration of functionalities across systems
US9959134B2 (en) Request processing using VM functions
US9558152B2 (en) Synchronization method, multi-core processor system, and synchronization system
US11301283B1 (en) Virtualization extension modules
US10402264B2 (en) Packet-aware fault-tolerance method and system of virtual machines applied to cloud service, computer readable record medium and computer program product
US9886327B2 (en) Resource mapping in multi-threaded central processor units
WO2013008326A1 (fr) Procédé de vérification de logiciel et système de vérification de logiciel
US20170046186A1 (en) Limited hardware assisted dirty page logging
CN115495278B (zh) 异常修复方法、设备及存储介质
US10831558B1 (en) Single-click ejection of peripheral devices associated with virtual machines
US10127064B2 (en) Read-only VM function chaining for secure hypervisor access
US20210342172A1 (en) Asynchronous management of unencrypted memory page list of a virtual machine
JPWO2013008326A1 (ja) ソフトウェア検証方法、およびソフトウェア検証システム
CN110622164B (zh) 用于驱动程序执行的系统、方法和计算机存储介质
US10241821B2 (en) Interrupt generated random number generator states
US20230393874A1 (en) Efficient pagefaults for virtual machines
US11221869B2 (en) Memory efficient host virtual address management for hypercalls
Russinovich Inside windows server 2008 kernel changes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11869351

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013523749

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11869351

Country of ref document: EP

Kind code of ref document: A1