JP2013041571A - Integration apparatus, program creation device, program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an integration device capable of identifying an error occurrence place of software from a code displayed at a time of error occurrence.SOLUTION: Integration apparatuses 200, 300 for displaying an error message at a time of detection of a failure during execution of a program 20 comprises: central processing units 201, 101 for executing a program; program storage means 205, 104 for storing an executable compression file in which a plurality of files are combined as a program; failure detection means 18 for detecting a failure on the basis of storage content of an address in which an execution result of a command is stored; and error message display means 19 for, when the failure detection means detects a failure, outputting an error message that includes version information of a program described in the command, file identification information of the file, and a line number of the command being executed in the file, to a display device.

Description

  The present invention relates to an embedded device that displays an error message when a failure is detected during execution of a program.

  An error message may be displayed when an error occurs when a computer-equipped device executes a program. The display of the error message has a meaning of notifying the user of the occurrence of the error, but may include a meaning of further proceeding to notify the user of the cause of the error.

  FIG. 1 is a diagram illustrating an example of a conventional error message. Description 1 is a message notifying the user of the occurrence of an error, Description 2 is a message notifying a typical handling method, and Description 3 is a message including the meaning of notifying the user of the cause of the error. How the description 3 is displayed depends on software, but the amount of information that can be displayed is often limited. Therefore, description 3 is coded, and the user grasps the cause of the error by referring to the error content corresponding to the code in a manual or the like. In addition, the user can notify the user of the cause of the error by notifying the support center of the code.

  Analysis of the cause of such an error may be troublesome for some users. For this reason, a technique for holding a code and error contents in a device that executes a program is known (for example, see Patent Document 1). Patent Document 1 discloses a device diagnostic apparatus having a table for associating events with failure sites. By having a table in the device, it is possible to reduce the necessity of referring to an analysis manual or making an inquiry to the support center when the user wants to specify the cause of an error.

  Conventionally, however, the code displayed when an error occurs can identify the cause of the error or the location where the error occurred, but the error location cannot be pinpointed on the source file. there were. That is, even if the cause of the error is different, the conventional code becomes the same code if the error is similar, and does not have information for uniquely specifying what kind of error has occurred. This is the same even if a table is provided in the apparatus as in Patent Document 1, and if the amount of information that the code has is small, it is difficult to accurately identify the failure site.

  For example, when a program is developed, IDE (Integrated Development Environment) is used, and IDE may display a line number if there is an error in the program. Also, if there is a grammatical error during compilation, the line number is displayed. However, it is difficult to incorporate IDE into a device as it is because of restrictions on execution speed and resources. In addition, since line numbers are not assigned to the compiled program, it is difficult to specify the line number of the program being executed when an error occurs at the stage where the device executes the program. This is the same in the interpreter language, and even if IDE assigns a line number to the source code at the time of editing, it is general that the interpreter language at the time of execution does not have a line number.

  In addition, in order to pinpoint the location where an error has occurred, for example, it is conceivable that a user or a support center analyzes the cause of the error using an error log. The error log includes a failure occurrence status, a displayed error message, and the like. Many programs generate an error log, so if there is an error log, it is easier to identify the cause of the error than at least the error message.

  However, since the error log is complicated for the user to analyze, it is often difficult for the user to identify the cause of the error from the error log. Further, in the case of an embedded device instead of a general-purpose computer, it is difficult for the user to access the error log in the first place.

  In addition, it is technically possible for the support center to analyze the error log by transmitting the error log to the support center. However, many users feel resistance to sending an error log including detailed information to the outside. Further, even when the user can analyze the error log, showing the error log to the user may enable detailed analysis of the device, which is not always a preferable measure.

  In view of the above problems, an object of the present invention is to provide an embedded device that can specify an error occurrence location of software from a code displayed when an error occurs.

  The present invention is an embedded device that displays an error message when a failure is detected during execution of a program, and stores a central processing unit that executes the program and an executable compressed file in which a plurality of files are combined as the program Program storage means, failure detection means for detecting a failure based on the stored contents of an address for storing an instruction execution result, and the version of the program described in the instruction when the failure detection means detects a failure Error message display means for outputting to the display device an error message including information, file identification information of the file, and a line number of the command being executed in the file.

  It is possible to provide an embedded device that can identify the error occurrence location of software from the code displayed when an error occurs.

It is a figure which shows an example of the conventional error message. It is a figure which shows an example of the error message of this embodiment. It is an example of the figure which shows the flow until an error cause is analyzed when an error generate | occur | produces in the apparatus which performs a program. It is a figure which shows an example of an apparatus. 2 is an example of a hardware configuration diagram of an information processing apparatus or an MFP. FIG. It is an example of the hardware block diagram of a communication terminal. It is a figure which shows an example of the schematic perspective view of a program production apparatus. It is an example of a functional block diagram of a program creation device and a program execution device. It is an example of a file code table. It is an example of the figure explaining the version of a program. An example of the version management table which a build tool produces | generates is shown. It is a figure which shows an example of an error code. It is an example of the figure explaining the example of a description of a source file. It is a figure which shows an example of the source file after being replaced by the error code. It is an example of the flowchart figure which shows the procedure in which a program production apparatus produces | generates an error code. It is an example of the flowchart figure which shows the procedure which displays an error message, when an apparatus or a communication terminal runs a program. (Example 2) which is a figure which shows an example of an error code. FIG. 10 is an example of a diagram illustrating a description example of a source file (second embodiment). It is a figure which shows an example of the error number table with which the 1st argument and the error number were matched. (Example 2) which is a figure which shows an example of the source file after being replaced by the error code. FIG. 10 is an example of a flowchart illustrating a procedure for generating an error code by the program creation device (second embodiment). FIG. 10 is an example of a flowchart illustrating a procedure for displaying an error message when a program execution device executes a program (Example 2); It is an example of a block diagram of an error notification system. It is an example of the flowchart figure which shows the operation | movement procedure of the program execution apparatus and the terminal for maintenance of a support center.

  Hereinafter, modes for carrying out the present invention will be described.

[Outline]
First, an error message displayed by the program execution device of this embodiment will be described.
FIG. 2 is a diagram illustrating an example of an error message according to the present embodiment. The error message displays the following three descriptions and an OK button.
Description 1: “An error has occurred”
Description 2: “Please contact the support center.”
Description 3: 0511-01C-0
The error message of this embodiment is characterized in that description 3 includes the line number of the source file. “01C” in description 3 indicates the line number of the source file in hexadecimal. “05” is the version of the program, and “11” is the name of the file in which the error occurred. Hereinafter, the entire description 3 is referred to as an error code.

  In most cases, the instruction executed by the computer when an error occurs does not include a line number, but description 3 includes what line the instruction corresponds to in the source file. Accordingly, if the user notifies the description 3 to the support center or the like, the support center or the like can pinpoint the instruction in which the error has occurred, and can analyze the cause of the error at an early stage.

  In FIG. 2, the error code is included in the error message. However, the error code may be displayed independently of the error message before and after the error message is displayed. The error code program version, file name, and line number may be displayed separately.

  An error in the present embodiment refers to a problem that can be detected by the program, in other words, an expected problem. On the other hand, unexpected problems that make it difficult to display an error message in the first place (for example, bugs that cause the program to hang up or problems that make it difficult to execute the program in hardware) are not included.

[Example of actions when an error occurs]
FIG. 3 is an example of a diagram showing a flow until an error cause is analyzed when an error occurs in the program execution device.
1. An error occurs and the program execution device displays an error message. As a result, the user notices the occurrence of an error.
2. When the user can identify the cause of the error from the error message and recover, the user continues to use the program execution device.

On the other hand, if the user cannot visually check the error message or examine it manually to find out the cause of the error and cannot recover, the failure information (error message, program version, error occurrence status, error log, etc.) is displayed. Notify your support center. Notification can be made by telephone or e-mail. Note that the user can notify the support center of failure information, not limited to the case where recovery is not possible. This is because many program execution devices can be restored by restarting.
3. The support center analyzes the cause of the error from the failure information. When the support center alone cannot restore the program execution device to the user or when the cause of the error cannot be specified, the failure information is notified to the development area of the program execution device manufacturer.
4). In the development zone, error cause analysis and countermeasures are performed based on the failure information.
5. The development zone reports the analysis results to the support center.
6). The support center notifies the user of the analysis result and, if necessary, the countermeasure.

  Here, in the analysis of “4.”, the cause of the error is easier for the development zone as the failure information contains more information. However, for example, not all of the above failure information is available, and there is a difference in difficulty of obtaining.

(i) Occurrence status of the failure (what operation occurred, operation performed before and after that, hardware environment, etc.)
(ii) Error message displayed to the user
(iii) The version of the program in which the failure occurred
(iv) Error log For example, (i) can be obtained if the user observes the operating state of the program execution device, but if it is not observed, only minimal information can be obtained. Further, the more detailed the occurrence of the failure is, the more preferable, but the more detailed, the more difficult it is to obtain information.

  Since the error message (ii) is displayed in many cases unless the program execution device hangs up, it is easy for the user or support center to obtain. However, as described above, sufficient information was not included for the user or the support center to analyze the cause of the error.

  (iii) By knowing the program version for the development area, it may be relatively easy to estimate the cause of the error specific to the version. The reason for the error specific to the version is that there is a high possibility that it has already been reported from other program execution devices or users. In order for the user to acquire the version, a user's conscious operation is required except for a program whose version is always displayed at the time of startup or after startup.

  In addition, since the versions are known, the versions of various files that make up the program are also found, which makes it easy to analyze the cause of an error caused by a specific file.

  The error log of (iv) can include all the information (i) to (iii). The error log includes information for specifying the detailed cause and location of the error, in particular, the name of the file in which the error has occurred and the version of the program, which are indispensable information for detailed analysis. Therefore, it is most desirable for a development zone to acquire this, but it is also the most difficult information to acquire. The reason is that, as described above, the user does not like to provide it to the outside, and the device manufacturer does not want the user to easily access it.

  In this embodiment, the support center can obtain information equivalent to the error log from the error code included in the error message even in a situation where it is difficult for the development zone to obtain the error log. In other words, the error code includes the version of the program, the name of the file in which the error occurred, and the line number of the source file. Can be pinpointed.

[Configuration example]
<Program execution device>
As will be described later, since the line number of the source file is displayed, the program executed by the program execution device already includes the line number. For this reason, the program execution device of the present embodiment may execute the program in any form such as a stand-alone type, a client terminal connected via a network, or a server.

  4A illustrates an example of a schematic perspective view of the information processing apparatus 100 as a stand-alone program execution device, and FIG. 4B illustrates an example of a schematic perspective view of the MFP 200. Each of them has a CPU and a program inside, and the CPU executes the program to execute processing specific to the program. If any error occurs, the information processing apparatus 100 or MFP (Multifunction Peripheral) 200 displays an error code.

  FIG. 4C is an example of a schematic configuration diagram of the communication system 301. A plurality of communication terminals (hereinafter referred to as communication terminals A and B, if distinguished) 300 and a server 400 are connected via a network. The communication terminal A is in a certain area (for example, the United States of America), and the communication terminal B is in another area (for example, Japan), and is connected to be communicable via a network via the server 400.

  Each of the communication terminals A and B has a camera, a microphone, and a speaker, and is connected locally to the display device. The voice uttered by the user near the communication terminal A is collected by the microphone of the communication terminal A and converted into an electrical signal, and then transmitted to the communication terminal B. The speaker of the communication terminal B converts the electrical signal into sound and outputs it from the speaker. The same applies to the video captured by the camera, and the communication terminal A converts the video captured by the camera of the communication terminal A into an electrical signal and transmits it to the communication terminal B. The communication terminal B converts the electrical signal into a video and displays it on the display device. Therefore, users in different regions can communicate with each other using audio and video. Examples of the display device include a projector and a liquid crystal display. As a specific example of such a communication system 301, a video conference system is known.

  Among the program execution devices in FIG. 4, the MFP 200 and the communication terminal 300 are called embedded devices. The error message of this embodiment is particularly effective in an embedded device that has few operations that a user can perform on a program execution device. In addition, although the clear definition of an embedded device is not generally prescribed | regulated, it is mentioned that a general information processing apparatus (PC: Personal Computer) is not included, for example.

  FIG. 5 shows an example of a hardware configuration diagram of the information processing apparatus 100 or the MFP 200. In the hardware configuration diagram of the MFP 200, only the part that executes the program 20 is taken out and described. The MFP 200 has functions such as a scanner, a plotter, and a facsimile in addition to those illustrated.

  The information processing apparatus 100 or the MFP 200 includes a CPU 201 that controls the operation of the entire apparatus, a ROM 202 that stores IPL (Initial Program Loader) and static data, a RAM 203 that is used as a work area of the CPU 201, a program 20 that the CPU 201 executes, The HD 204 that stores various data, the HDD (Hard Disk Drive) 205 that controls the reading or writing of various data to the HD 204 according to the control of the CPU 201, and the reading or writing (storage) of data to the recording medium 206 such as a flash memory are controlled. Media drive 207, display 208 for displaying various information such as cursors, menus, windows, characters or images, network I / F 209 for transmitting data using communication network 2, characters A keyboard 211 having a plurality of keys for inputting numerical values and various instructions, a mouse 212 for selecting and executing various instructions, selecting a processing target, moving a cursor, etc., and a CD as an example of a removable recording medium A CD-ROM drive 214 for controlling reading or writing of various data to / from a ROM (Compact Disc Read Only Memory) 213, etc., and for electrically connecting the above components as shown in FIG. A bus line 210 such as an address bus or a data bus is provided.

  Note that the program 20 may be recorded in a computer-readable recording medium such as the recording medium 206 or the CD-ROM 213 and distributed as a file in an installable or executable format. The program 20 may be distributed to the information processing apparatus 100 or the MFP 200 in a file that can be installed or executed from a server (not shown).

  FIG. 6 is an example of a hardware configuration diagram of the communication terminal 300. As shown in FIG. 6, the communication terminal 300 of this embodiment includes a CPU 101 that controls the operation of the entire communication terminal, a ROM 102 that stores IPL, static data, and the like, and a RAM 103 that is used as a work area for the CPU 101. , A program 20, a flash memory 104 that stores various data such as image data and audio data, an SSD (Solid State Drive) 105 that controls reading or writing of various data to the flash memory 104 according to the control of the CPU 101, and a flash memory The media drive 107 that controls reading or writing (storage) of data to the recording medium 106, the operation button 108 that is operated when the destination of the terminal 10 is selected, and the power supply of the terminal 10 are switched ON / OFF Because of the power switch 109, using the communication network 2 and a network I / F (Interface) 111 for data transmission. Note that the recording medium 106 is detachable from the communication terminal 300.

  The communication terminal 300 includes a built-in camera 112 that captures an image of a subject under the control of the CPU 101 to obtain image data, an image sensor I / F 113 that controls driving of the camera 112, a built-in microphone 114 that inputs sound, The built-in speaker 115 that outputs sound, the sound input / output I / F 116 that processes input / output of sound signals between the microphone 114 and the speaker 115 according to the control of the CPU 101, and the image on the external display device 120 according to the control of the CPU 101 A display I / F 117 for transmitting data, an external device connection I / F 118 for connecting various external devices, and an address bus for electrically connecting the above components as shown in FIG. And a bus line 110 such as a data bus.

  The display device 120 shown in the figure is a liquid crystal display configured by a liquid crystal or organic EL that displays an image of an object, an operation icon, or the like, but may be a projector. The display device 120 is connected to the display I / F 117 by a cable 120c.

  The camera, the microphone, and the speaker do not need to be built in the communication terminal 300, and may be an external type connected to the external device connection I / F 118 by a USB (Universal Serial Bus) cable or the like.

  The flash memory 104 does not always store the program 20. This is because in the case of the communication system 301, the program 20 that is optimal for the type of the communication terminal 300 is downloaded from the server 400. However, since the program 20 that outputs an error message is stored in the flash memory 104 at the time of execution, the program 20 can be regarded as an integral part of the communication terminal 300.

  The program 20 is a file in an installable or executable format, and can be distributed in a state where it is recorded on a computer-readable recording medium such as the recording medium 106.

<Program creation device>
In the present embodiment, the line number of the source file is included in the program 20 executed by the program execution device (the information processing apparatus 100, the MFP 200, and the communication terminal 300). Therefore, there is a device for creating this special program 20 (hereinafter referred to as a program creation device). The program creation apparatus may be an information processing apparatus that operates a general-purpose OS (for example, Windows (registered trademark), UNIX (registered trademark), or Linux (registered trademark)), and is functional with the information processing apparatus 100 of FIG. May not make a big difference. However, since the program creation device is generally in the manufacturer, it is distinguished from the program execution device that executes the program 20.

  7A shows an example of a schematic perspective view of the program creation device 500, and FIG. 7B shows an example of a hardware configuration diagram of the program creation device 500. The program creation device 500 includes a CPU 501, a RAM 502, a ROM 503, a storage medium mounting unit 504, a communication device 505, an input device 506, a drawing control unit 507, and an HDD 508 that are mutually connected by a bus. The CPU 501 reads out an OS (Operating System) and a build tool 511 from the HDD 508 and executes them to provide various functions and generate corrected document image data.

  The RAM 502 is a working memory (main storage memory) that temporarily stores data necessary when the CPU 501 executes the build tool 511, and the ROM 503 is a BIOS (Basic Input Output System), an IPL for starting an OS, a static Data is stored.

  A storage medium 510 is detachably attached to the storage medium mounting unit 504, and data recorded in the storage medium 510 is read and stored in the HDD 508. The storage medium mounting unit 504 can also write data stored in the HDD 508 to the storage medium 510. The storage medium 510 is, for example, a USD memory or an SD card.

  The input device 506 is a keyboard, a mouse, a trackball, or the like, and accepts various operation instructions from the user to the program creation device 500. The HDD 508 may be a nonvolatile memory such as an SSD, and stores various data such as an OS and a build tool 511.

  The communication device 505 is a NIC (Network Interface Card) for connecting to a network such as the Internet, and is, for example, an Ethernet (registered trademark) card.

  The drawing control unit 507 executes the build tool 511 and interprets the drawing command written in the graphic memory, generates a screen, and draws it on the display 509.

  The build tool 511 is a file in an installable or executable format, and can be distributed from a state recorded in the storage medium 510 or a server (not shown).

[Function block]
FIG. 8 shows an example of a functional block diagram of the program creation device 500 and the program execution device. The program creation device 500 builds the source file using the build tool 511 and creates the program 20. The build tool 511 includes a compiling unit 12, a linkage unit 15, a compression unit 16, a file code generation unit 11, a version reception unit 13, and a code replacement unit 14. Among these, the code replacement unit 14 may exist independently, or the compiling unit 12 may have a part of the function.

  The compile unit 12, the linkage unit 15, and the compression unit 16 are all known functions provided by the build tool 511. That is, the compiling unit 12 compiles a source file described in C, C ++, JAVA (registered trademark, hereinafter omitted), and creates an object module file for each source file. The linkage unit 15 creates an object file by linking a plurality of object module files.

  The compression unit 16 combines and compresses files in the directory including the designated directory structure. For example, extensions of “* .jar”, “* .war”, and “* .exe” are attached to the compressed file. The compressed file is the program 20. The program execution device can decompress and execute the compressed program 20, but can execute it as an execution file as it is.

The operation content of the build tool 511 is defined by the build file 22. The build file 22 is described in XML, and defines a build method for building a source file to generate a project (the program 20 of the present embodiment).
Description B1 defines the project name “program A”.
Description B2 defines variable names, and directory names of files, home, bin, and js are stored in the variables. Files and home already exist.
Description B3 defines the creation of bin and js directories.
Description B4 defines that the source file in files is compiled and copied to a file called bin.
Description B5 defines copying a file called calk.js in files to a directory called js.
Description B6 defines that a compressed file called “programA.war” is generated by compressing a directory and files under home.

  When the developer gives an instruction to start a build, the build tool 511 reads such a build file 22 and starts the build. The build file 22 can be described by the developer, or can be automatically created by analyzing the contents of each source file being developed by the build tool 511.

  The file code generation unit 11 specifies all the files to be built, and generates a file code table 21 by associating file codes (identification information) that are not duplicated with the files. In the build file 22 in FIG. 8, the files in the files directory to be compiled and the copy source file calk.js are all the files to be built. Therefore, a unique file code may be assigned to files in the files directory.

  FIG. 9 shows an example of the file code table 21. In the file code table 21, file codes that are not duplicated are associated with all source files that constitute the program 20. For example, the file code generation unit 11 refers to the build file 22 and extracts all source files of files compiled by the description B4 and a source file from which the description B5 is copied. A file code is assigned to each file name.

  The file code table 21 may be created by a developer. In this case, the file code generation unit 11 is unnecessary.

  The version receiving unit 13 receives an input of the version of the program 20 from the developer. The version of the program 20 will be described later.

  The code replacement unit 14 replaces a specific function described in each file with the version of the program 20, the file code, and the line number of the source file (after conversion to hexadecimal). That is, an error code is generated. By this replacement, the program 20 can display the line number of the source file when an error occurs.

  Whether the code replacement unit 14 is in the compiling unit 12 or outside the compiling unit 12 corresponds to the difference in whether the file to be built needs to be compiled, and the processing contents are the same. . For example, since a file written in JavaScript (registered trademark, hereinafter omitted) is not compiled, the code replacement unit 14 outside the compiling unit 12 generates an error code. Since a file described in C ++ or JAVA is compiled, the code replacement unit 14 of the compiling unit 12 generates an error code. If the code replacement unit 14 generates an error code before compilation, only the code replacement unit 14 outside the compilation unit 12 may be installed.

  The program 20 generated by the build tool 511 in this way includes an error detection unit 18 and an error message display unit 19 in addition to various functions unique to the program 20. The error detection unit 18 detects the occurrence of an error by determining the contents of a variable using an if statement or the like. The error message display unit 19 detects the occurrence of an error and draws the error message on the displays 208 and 120.

  The program DL unit 17 is mainly mounted on the communication terminal 300. For example, when the communication terminal 300 is turned on, the IPL is activated and causes the CPU 101 to execute the program DL unit 17. The program DL unit 17 downloads the program 20 from the server 400 by specifying the IP address of the known server 400 in advance using, for example, an FTP command and connecting to the server 400 and specifying the file name of the program 20 using the get command.

  Note that when the communication terminal 300 is powered off, the communication terminal 300 erases the program 20 from the flash memory 104. Thereby, it is possible to prevent the program 20 from being stolen from the communication terminal 300 while the power is off.

[Program version]
FIG. 10 is an example of a diagram for explaining the version of the program 20. A program 20 having a certain size is generated from a plurality of source files through a process called build. In the figure, a C ++ language source file called main.cpp, a header file used by main.cpp called base.h, and a JavaScript source file called calk.js (it is called a source file because JavaScript is not compiled but is a build target) It is shown that one program 20 is configured from the above.

  Build means creating an “executable file” by combining these files. The build is performed by the program creation device 500 used by the developer. In general, build tools 511 such as Make and ANT are commercially available, and an executable file that is the program 20 is created when the program creation device 500 executes the build tool 511 (for example, * .war, *. jar, * .exe and other files).

The version of the program 20 is managed by a combination of versions of the plurality of files. For example, when only the calk.js version is changed (only calk.js is updated and other files are not changed), the version of the program 20 is updated by the calk.js version. In the figure, it is as follows.
calk.js Ver1: Program version 0.1.0.0
calk.js Ver2: Program version 0.1.0.1
calk.js VerX: Program version 0.2.0.5
The version of the program 20 is set by the developer for the build tool 511 at the time of building, for example. The version of the program 20 can be managed by the developer by recording it together with the version of each source file, but a dedicated version management system is often used. As a version management system, for example, freeware CVS (Concurrent Versions System), SVN (Subversion), Git, etc., commercial VisualSourceSafe (registered trademark), and the like are known. In the case of SVN, the version of the program 20 is given as follows, for example.

  s1) The developer registers a directory structure in which source files are registered in a tree form in the repository by using a version management system command (import). The repository is a storage location for each resource (such as a source file). At this time, the version control system gives revision 1 to the project as an initial version.

  s2) The developer may edit one or more of the source files. When a developer wants to record a combination of source files after editing, the developer uses a version control system command (commit) to reflect the edited result in the repository. The version control system increases the project revision to 2. A new version is given to the source file.

  s3) When the developer creates the program 20 from the project by building each source file, a tag name is given using a command (copy) of the version management system. By giving a tag name, the version of each source file at that time or the source file itself of a different version is associated with the tag name and stored by the version management system. Generally, “tag name = version of program 20” is given.

  By giving the tag name, if the version of the program 20 is known, the version management system can uniquely identify each source file used for the build.

  Thereafter, the build tool 511 performs the build by the developer's operation without changing the directory structure and the contents of the source file (no new change is made) since the tag name is given. When executing the build, the developer specifies the tag name as the version of the program 20.

  Later, in order to retrieve the source file corresponding to the version of the program 20, the developer designates the tag name and causes the version management system to identify the source file.

  Since there are IDEs that can perform build and version management, it is not always necessary to prepare the build tool 511 and the version management system separately.

  FIG. 11 shows an example of a version management table generated by the build tool 511. The build tool 511 acquires the version or time stamp of each source file and registers it in association with the version of the program 20 set by the developer. Therefore, if the version of the program 20 is detected, the version of each file constituting the version of the program 20 is specified by referring to the version management table. The version control table is managed in the development zone.

  Note that the source files in FIG. 10 are not the same in the type (for example, description language) of each source file, but the build tool 511 only selects files of a single type (for example, only files described in the C ++ language). Sometimes build. In this case, the build tool 511 only compiles and links. Whether such partial processing is called build or compilation, for example, is just a difference in name, and even if there is only a single type of source file, the program execution device displays the line number in the same way can do.

〔Error code〕
FIG. 12 is a diagram illustrating an example of an error code. In FIG. 12, the entire error code is 10 digits. A description will be given with digit numbers from the left. The upper two digits of the error code contain the last two digits of the program 20 version. For example, if the version of the program 20 is 0.2.0.5, “05” is obtained. The reason why only the last two digits are used is to prevent the user from making a mistake when notifying the support center that the error code is too long. Incidentally, "-" (hyphen) is included in the error code to make the error code easier to see, and the hyphen itself has no meaning.

  Depending on the rules for versioning, when the developer increments the version one by one in decimal, 100 versions can be identified with only the last two digits. Therefore, only the last two digits of the version are sufficient for analyzing the error code.

  The two characters of the third to fourth digits of the error code are the file code of the source file that output the error message. The file code is a non-overlapping hexadecimal number that identifies the file name of the source file as described with reference to FIG. If there are 2 digits in hexadecimal, 255 files can be identified. The large-scale program 20 lacks file code, but the general-scale program 20 is sufficient. In addition, when the file code is insufficient, the number of digits is increased by using a hyphen in the fifth digit. The reason why the file name is displayed in the form of a file code is not only to make the length of the error code as short as possible, but also to prevent the user from grasping information such as the function of the program 20 from the file name. is there.

  The 6th to 8th three characters indicate the line number of the source file that output the error message in hexadecimal. In the case of 3 digits in hexadecimal, a maximum of 4096 lines can be expressed. This is insufficient when the amount of code of one source file is large, but generally it is not often insufficient. In addition, if the 4096 lines are insufficient, a 9th digit hyphen is used to increase the number of digits. The reason why the line number is displayed in hexadecimal is to shorten the length of the error code.

  One character of the 10th digit is an arbitrary character. This is used by the developer of the source file to describe, for example, information useful for analyzing the cause of the error when creating the source file. For developers, it is easier to analyze the cause of an error with an arbitrary character.

[Example of source file]
FIG. 13 is an example of a diagram illustrating a description example of a source file. The source file in the figure has an integer line number that increases by one. The actual source file itself does not include line numbers, but IDEs and editors display serial numbers from the first line to support the developer.

  In FIG. 13, a function “printErrorDialog” is used to display an error message (lines 11, 28, 105). When this function is executed by the program execution device, the program execution device displays an error message in a format (having descriptions 1 to 3 and one OK button) as shown in FIG.

This function takes three arguments.
printErrorDialog (errorTitle1, errorMessage1, createCode (_reason);
The first argument errorTitle1 specifies the description 1 in FIG. 2, and the second argument errorMessage1 specifies the description 2. In errorTitle1 and errorMessage1, a character string is set in a line (not shown), and the character string is stored at a predetermined address in the RAMs 203 and 103, the HD 204, and the flash memory 104. When executing this function, the program execution device reads the character string of the address associated with errorTitle1 and the character string of the address associated with errorMessage1 from the RAMs 203 and 103, the HD 204, and the flash memory 104.

  The third argument “createCode ()” of the “printErrorDialog” function corresponds to the description 3 and is to be replaced with an error code. createCode () is a function for creating an error code and takes one argument. When executing printErrorDialog, createCode () does not function as a function because it is a character string. Therefore, variables and error codes may be replaced instead of functions. Since the createCode () function displays the error code in the conventional error message, if this function is replaced with the error code, the developer will use the original source file to display the error code of this example. You can change the source code.

  The code replacement unit 14 replaces createCode () with the version, file code, and line number of the program 20, and replaces the argument of createCode () with any one character of the error code. An arbitrary character is given as a variable in createCode () on the 11th and 28th lines, and is given as a character constant “2” on the 105th line. Since “_reason =“ 0 ”” is described as described in the third line, if createCode () in the 11th and 28th lines is replaced, one arbitrary character becomes “0”. On the other hand, when createCode () on the 105th line is replaced, an arbitrary character becomes “2”. The meaning of an arbitrary character is managed by the developer of the source file in a table that associates the character with its contents.

  In FIG. 13, a total of three “printErrorDialog” functions are described in the 11th, 28th, and 105th lines. Since the developer changes the argument depending on the location and situation of the error (that is, depending on the immediately preceding process), the contents of description 1 and description 2 also change. Of course, as in the 11th and 28th lines, multiple “printErrorDialog” functions may have the same argument.

  As described above, if there are a plurality of portions using the same message only by descriptions 1 and 2, it is difficult for the developer to distinguish the error message output from where it is, or not at all. However, by embedding the error code in the source code as in this embodiment, even if the error message descriptions 1 and 2 are the same, it is possible to uniquely identify the error message output from which part (line) of which source file. Can be determined.

  For example, if the error code includes a line number of 28 lines, the developer can specify that the output error message is displayed by the “printErrorDialog” function on the 28th line of the source file. Therefore, the developer can specify that there is a process causing the error near the 28th line of the source file. In the example of FIG. 13, the process in which an error has occurred is several lines before the line number included in the error code.

  Immediately before the “printErrorDialog” function, for example, an error occurrence determination process by an if statement is described. In the error occurrence determination process, an error that can occur in the process immediately before the determination process is assumed by the developer, and an optimal determination condition is described for detecting whether such an error has occurred. For example, the error message on the 11th line is displayed when the value “failed” is set in the variable operation, and the error message on the 28th line is displayed except for “0” in the variable errorOccurred. The value is set, and the error message on the 105th line is displayed when the variable getValue is set to a value of null (nothing is set). Therefore, an error peculiar to the processing can be reliably detected. The variable operation, variable errorOccurred, and variable getValue are actually stored at predetermined addresses in the RAMs 203 and 103, the HD 204, and the flash memory 104. If the program execution device accesses this address by the variable name, the occurrence of an error can be determined.

  Note that the determination of the occurrence of an error by an if statement is an example, and the occurrence of an error may be determined by a Switch statement, for example.

FIG. 14 is a diagram illustrating an example of a source file after being replaced with an error code. As can be seen by comparing with FIG.
The 11th line CreateCode (_Reason) is 0511-00B-0
CreateCode (_Reason) on line 28 is 0511-01C-0
CreateCode ('2') on line 105 is 0511-069-1
Has been replaced respectively.

[Operation procedure]
FIG. 15 is an example of a flowchart illustrating a procedure in which the program creation device 500 generates an error code. This processing procedure exemplifies the case where the code replacement unit 14 is outside the compiling unit 12, but the processing content is the same even when the code replacement unit 14 of the compiling unit 12 processes, only the execution timing is different. .

  When building each file, the developer sets the version of the program 20 after the build in the program creation device 500 (S10). The version receiving unit 13 of the program creation device 500 receives a version input.

  Next, the file code generation unit 11 creates a file code table 21 (S20). The source file to be built can be specified from the build file 22. In the example above, the files below the files directory correspond.

  Next, the code replacement unit 14 sequentially reads out the source files for which the file code table 21 is created (S30). Thereby, the file code of the source file currently focused on is specified.

  When the code replacement unit 14 reads a new source file, the code replacement unit 14 reads instructions in order from the first line (S40). Even if one instruction is described over two lines or more, it is read line by line. In other words, it can be read without being affected by the format or grammar of the instruction, but a shift of 1 to 2 lines does not constitute a specific major obstacle to the error cause. Also good.

  Next, the code replacement unit 14 determines whether the readCode includes a createCode () function (S50). The argument of the createCode () function may or may not have any value.

  When the createCode () function is not included (No in S50), the process returns to step S40.

  When the createCode () function is included (Yes in S50), the code replacement unit 14 creates an error code (S60). In creating the error code, the version, file code, and line number of the program 20 are used. Any one character described above may or may not be replaced. The code replacement unit 14 acquires the version of the program 20 input by the developer to the program creation device 500 and extracts the lower two digits. Next, the file code associated with the file name of the currently focused file is read from the file code table 21. Next, the currently read line is converted into a hexadecimal number using the line number as it is. Also, if there is an argument of createCode () function, specify any single character. Since the process in which the error occurred is several lines before, a value obtained by subtracting several lines from the currently read line may be converted into a hexadecimal number as a line number. An error code is created by placing these character strings and hyphens in predetermined digits.

  The code replacement unit 14 replaces the createCode () function with the created error code (S70).

  Then, the code replacement unit 14 determines whether or not the last line of one source file has been reached (S80). If the final line has not been reached (No in S80), the process returns to step S40. If the last line has been reached (Yes in S80), the process proceeds to step S90.

  When reaching the last line, the code replacement unit 14 determines whether or not all files to be built (all source files in the file code table 21) have been processed (S90).

  Until all the source files to be built are processed (No in S90), the processing from step S30 is repeated. When all the files to be built have been processed (Yes in S90), the build unit combines and compresses the files (S100). More specifically, the compiling unit 12 compiles the source file to be compiled, and the linkage unit 15 links and saves it in a specific directory. Also, the build tool 511 copies a source file that only needs to be copied to a specific directory. Finally, the compression unit 16 combines and compresses a plurality of files under the directory specified by the build file. By doing so, the program 20 which is an execution file is created.

  The created program 20 is installed in the program execution device via a storage medium or a network. In the case of the communication terminal 300, it is downloaded from the server 400 when the power is turned on.

  FIG. 16 is an example of a flowchart illustrating a procedure for displaying an error message when the program execution device executes the program 20.

  If there is no branch or subroutine call, the program execution device executes the program 20 in the order of addresses (S110).

  Then, the error detection unit 18 such as an if statement determines whether an error is detected (S120). When the error detection unit 18 detects an error (Yes in S120), the error message display unit 19 creates an error message (S130). Specifically, the character string stored in association with errorTitle1, which is the first argument of the PrintErrorDialog function, is read from the RAM 203, 103, HD 204, and flash memory 104, and stored in association with errorMessage1, which is the second argument. The read character string is read from the RAMs 203 and 103, the HD 204, and the flash memory 104. Further, for example, a character string “0511-00B-0” as three arguments is read from the RAMs 203 and 103, the HD 204, and the flash memory 104. The arrangement position of each description 1 to 3 is specified by the developer when creating the source file as an attribute of the PrintErrorDialog function.

  The error message display unit 19 displays the error message on the displays 208, 120, etc. (S140). As a result, the line number where the error occurred in the error code is displayed as shown in FIG. 2, so that the user can notify the support center of the error code. When the user presses the OK button, the program execution device resumes processing from the next instruction of the PrintErrorDialog function.

  The support center or development zone refers to the version management table and identifies the version of each file associated with the version of the program 20 included in the error code. Next, the support center and the development zone refer to the file code table 21 and identify the file name associated with the file code included in the error code. As a result, the source file in which the error has occurred and its version can be specified. The support center and development zone identify the location of the error in the source file by the line number included in the error code. Therefore, the instruction in which the error has occurred can be pinpointed.

  In the present embodiment, a program execution device and a program creation device that display error codes different from those in the first embodiment will be described.

〔Error code〕
FIG. 17 is a diagram illustrating an example of an error code according to the present embodiment. The error code in FIG. 17 has a total of 12 digits. A description will be given with digit numbers from the left. This embodiment is characterized in that an error number is assigned to four characters of 1-4 digits of the error code.

  The error number is identification information that uniquely identifies the error content (or collects several errors). The error code of the first embodiment is based on the premise that the developer analyzes the error code with reference to the source code. The user notifies the support center of the message and the error code. However, when the message or error code is long or there are many similar messages or error codes, there is a possibility that the user cannot be notified correctly.

  The upper 4 digits of the error code are for solving this problem. In addition, the manufacturer of the program execution device should distribute a manual describing the error contents and solutions corresponding to the error numbers to the user side, and prepare a Web page that displays the error contents and solutions from the error numbers. Is possible. By referring to the manual or the like based on the upper 4 digits of the error code, the user can be more likely to have an opportunity to eliminate the cause of the program failure without contacting the support center.

  The hyphen in the fifth digit of the error code is a symbol for distinguishing the error number from others. It does not necessarily have to be a hyphen, and may be "_" "" (space), ":" "/", or the like. Also, it is not impossible to describe error numbers without hyphens.

  The two characters of 6 and 7 digits are the same as the 1 and 2 digits of the error code in FIG. 12 (the last 2 digits of the version of the program 20), and the 2 characters of 8 and 9 digits are the error code of FIG. It is the same as 3 or 4 digits (file code of the source file that output the error message).

  The hyphen in the fifth digit of the error code in FIG. 12 is omitted in the error code in FIG. This is because the error number and other codes are clarified by setting the hyphen to one of the fifth digit hyphens in the error code of FIG. The code other than the error code (6-12 digits) is used by the development zone in the same manner as in the first embodiment. Also, omitting the hyphen can prevent the error code from becoming too long.

  Three characters of 10-12 digits are the same as the 6-8 digits of the error code in FIG. 12 (line number of the source file).

  The 9th and 10th digits of the error code in FIG. 12 are deleted. This is to prevent the error code from becoming long. However, the error code of FIG. 17 may be added to the 13th and 14th digits without being deleted.

  The error number is described in the upper 1-4 digits, but the position of the error number is not limited to the upper 1-4 digits. The description position of the version of the program 20 and the line number of the source file other than the error number is not limited to the example of FIG. The number of digits of the error number is not limited to four digits, and may be three digits or less, or five digits or more.

[Source file example]
FIG. 18 is an example of a diagram illustrating a description example of a source file. In FIG. 18, the common parts with FIG. Similar to the first embodiment, a function “printErrorDialog” is a function for displaying an error message. However, the printErrorDialog function of this embodiment takes two arguments.

  The first argument error1 (or error2) is associated with an error number in advance by the error number table. In addition, since the first argument is associated with the error number, description 1 in which the first argument is associated in Example 1 and description 2 in which the second argument is associated are referred to as the first argument. It is registered in the error number table in a linked form. For this reason, the second argument of the first embodiment is omitted.

  The third argument createCode () is to be replaced with an error code. In the present embodiment, since an arbitrary character is not included in the error code, the argument of createCode () is not used.

FIG. 19 is a diagram showing an example of the error number table 31 in which the first argument is associated with the error number, description 1 and description 2. The error number table 31 is stored in, for example, the HDD 508 of the program creation device 500 and the HD 204 and SSD 105 of the program execution device. The error number table 31 has fields of “errorName”, “errorNumber”, “errorTitle”, and “errorMessage”.
“ErrorName”: The value that can be the first argument of the “printErrorDialog” function is registered. “ErrorNumber”: The error number in the error code is registered. “ErrorTitle”: The error name (simple contents of the error) is registered. "ErrorMessage": Error message (specific content of error) is registered In this way, the first argument of the printErrorDialog function of the source file is registered as "errorName". The error message description 1 displays “errorTitle” and the description 2 displays “errorMessage”.

  The code replacement unit 14 reads the error number and descriptions 1 and 2 with reference to the error number table 31 based on the first argument. Also, createCode () is replaced with an error number, program 20 version, file code, and line number. As a result, createCode () is replaced with an error code.

FIG. 20 is a diagram illustrating an example of a source file after being replaced with an error code. As can be seen by comparing with FIG.
The 11th line CreateCode () is "0001-051100B"
CreateCode () on line 28 is "0001-051101C"
CreateCode () on the 105th line is "0002-0511069"
Has been replaced respectively.

  As described above, the 1-4 digits of the error code are replaced with the error number.

[Operation procedure]
FIG. 21 is an example of a flowchart illustrating a procedure in which the program creation device 500 generates an error code. The procedure of FIG. 21 is different from FIG. 15 in that step S55 is added.

  That is, when the createCode () function is included in the line read from the source file (Yes in S50), the code replacement unit 14 refers to the error number table 31 and identifies the error number (S55). That is, the code replacement unit 14 reads the first argument (error1 or error2 in FIG. 18) of the printErrorDialog function having the createCode () function as the second argument.

  Then, “errorNumber” of the record whose first argument is registered in “errorName” in the error number table 31 is read. This is the error number. Further, the code replacement unit 14 specifies the version, file code, and line number of the program 20 in the same manner as the procedure of FIG. Thereby, the error code of FIG. 17 can be generated.

  The code replacement unit 14 replaces the createCode () function with the created error code (S70). The subsequent processing is the same as in the first embodiment.

  FIG. 22 is an example of a flowchart illustrating a procedure for displaying an error message when the program execution device executes the program 20.

  If there is no branch or subroutine call, the program execution device executes the program 20 in the order of addresses (S110).

  Then, the error detection unit 18 such as an if statement determines whether an error is detected (S120). When the error detection unit 18 detects an error (Yes in S120), the error message display unit 19 displays “errorTitle” of the record in which the first argument of the PrintErrorDialog function is registered in “errorName” in the error number table 31. “ErrorMessage” is read (S125).

  Next, the error message display unit 19 creates an error message (S130). Specifically, for example, a character string “0001-051100B” as the second argument is read from the RAMs 203 and 103, the HD 204, and the flash memory 104. This is description 3, and an error message is created with “errorTitle” as description 1 and “errorMessage” as description 2. The arrangement position of each description 1 to 3 is specified by the developer when creating the source file as an attribute of the PrintErrorDialog function.

  The error message display unit 19 displays the error message on the displays 208, 120, etc. (S140). As a result, the error code including the error number is displayed as a part of the error message.

  Therefore, the user can notify the support center of the error code. Further, it becomes possible to check error contents and solutions based on error numbers from a manual or a web page. When the user presses the OK button, the program execution device resumes processing from the next instruction of the PrintErrorDialog function.

  As described above, according to the program execution device and the program creation device of the present embodiment, in addition to the effects of the first embodiment, the user can check the error content and the solution.

  In this embodiment, a program execution device that notifies an error message to a support center will be described.

  FIG. 23 shows an example of a configuration diagram of the error notification system 700. A plurality of program execution devices are communicably connected to a support center maintenance terminal 600 via a network. Since the hardware configuration of the support center maintenance terminal 600 is the same as that of the information processing apparatus 100, the illustration is omitted.

  In the program execution device, the IP address of the maintenance terminal 600 of the support center is registered in advance. The terminal 600 for maintenance of the support center may be specified by a URL instead of an IP address. In addition, identification information is registered in advance in the program execution device. This identification information is information for uniquely specifying the program execution device, and is a combination of numerical values, alphabets or symbols, or a combination of any one or more of these.

  When notifying the error message to the support center, the program execution device transmits identification information to the support center.

  The support center maintenance terminal 600 has user information associated with the identification information. The user information is information such as a company name, department name, address, and contact information. The support center can identify the user of the program execution device based on the identification information and provide after-sales service.

  Some users do not like the user information specified from the identification information. Therefore, the user can set prohibition of automatic transmission of identification information by the program execution device to the program execution device. Alternatively, even if the automatic transmission of the identification information is permitted, the user can request the support center to prohibit the registration of the user information.

  The support center maintenance terminal 600 stores an error number table 31 and detailed error information. The error number table 31 is the same as that in the second embodiment. The detailed error information has the detailed contents of the error in association with the error number. That is, the detailed error information is more detailed information than “errorTitle” and “errorMessage” in the error number table 31.

  Since the maintenance terminal 600 of the support center has the error number table 31, the maintenance terminal 600 can display an error message on the display of the terminal 600 based on the error number received from the program execution device. Further, the maintenance terminal 600 can display detailed error information on the display of the terminal 600 based on the error number received from the program execution device. Further, the maintenance terminal 600 of the support center can display the identification information of the program execution device or the user information of the program execution device.

  Therefore, even if the user of the program execution device does not notify the support center of the error code, the support center can identify not only the error message but also the program execution device (or user) in which the error has occurred, and an error has occurred. The program code instructions can be pinpointed.

  FIG. 24 is an example of a flowchart showing an operation procedure of the program execution device and the maintenance terminal 600 of the support center.

  When the program execution device executes the program, an error occurs (S210). As described in the second embodiment, the program execution device creates an error message. The program execution device according to the present embodiment transmits the entire error message or at least the error code and the identification information of the error message to the maintenance terminal 600 of the support center (S220).

  The support center maintenance terminal 600 receives the identification information and the error code (S230).

  The maintenance terminal 600 of the support center extracts a 1-4 digit error number from the error code (S240).

  The maintenance terminal 600 of the support center creates an error message by referring to the error number table 31 based on the error number, and reads error detailed information based on the error number (S250).

  The maintenance terminal 600 of the support center displays identification information, an error message, and detailed error information on the display (S260).

  As described above, in the error notification system 700 according to the present embodiment, the program execution device transmits the identification information and the error code, and the support center maintenance terminal 600 displays the identification information. Device can be identified. In addition, since an error message is displayed, the instruction of the program code in which the error has occurred can be pinpointed. Moreover, since detailed error information is displayed, the support center can identify the error content and grasp the solution.

DESCRIPTION OF SYMBOLS 11 File code production | generation part 12 Compile part 13 Version reception part 14 Code replacement part 15 Linkage part 16 Compression part 17 Program DL part 18 Error detection part 19 Error message display part 20 Program 31 Error number table 100 Information processing apparatus 200 MFP
300 Communication Terminal 301 Communication System 400 Server 500 Program Creation Device 600 Support Center Maintenance Terminal 700 Error Notification System

JP 2006-201927 A

Claims (13)

An embedded device that displays an error message when a failure is detected during program execution.
A central processing unit for executing the program;
Program storage means for storing an executable compressed file in which a plurality of files are combined as the program;
A failure detection means for detecting a failure based on the stored contents of the address storing the execution result of the instruction;
When the defect detection means detects a defect, an error message including version information of the program, file identification information of the file, and a line number in the file of the instruction being executed is displayed in the instruction. An embedded device having an error message display means for outputting to the apparatus.   The embedded device according to claim 1, wherein the error message further includes an error number for identifying error contents. The error message display means reads the version information, the file identification information, and the line number described in the program from a predetermined address of a memory included in the embedded device, and a predetermined position of the error message. To place in the
The embedded device according to claim 1, wherein the embedded device is a device. The error message display means is associated with the first character string associated with the first argument of the instruction described in the program and the second argument of the instruction described in the program. The second character string is read from a predetermined address of the memory included in the embedded device and is arranged at a predetermined position of the error message.
The embedded device according to claim 3. The first character string is a character string meaning that a failure has occurred, and the second character string is a character string meaning a corresponding method,
The embedded device according to claim 4. Corresponding to the first argument of the instruction described in the program, it has an error table in which the first character string and the second character string are registered,
The error message display means reads the first character string and the second character string associated with the first argument of an instruction described in the program in the error table, and Place it at a predetermined position in the message,
The embedded device according to claim 3. The first character string is a character string meaning an error name, and the second character string is a character string meaning an error content.
The embedded device according to claim 6.   The embedded device according to claim 1, further comprising a program download unit that downloads the program from a server connected via a network.   The embedded device according to claim 2, further comprising: a transmission unit configured to transmit the error message including at least the error number and the identification information of the embedded device to an information processing apparatus connected via a network. A program creation device for creating a compressed file that can be executed by combining a plurality of files,
File storage means for storing the plurality of files and file designation information for designating the files to be combined;
Version information receiving means for receiving input of version information of the program;
Identification table creating means for creating a file identification table by giving file identification information to each of the plurality of files designated by the file designation information;
A predetermined symbol described in the file, the version information received by the version information receiving means, the file identification information of the file registered in the file identification table, and a line in which the symbol is described, or Symbol replacement means to replace with the line number of a nearby line,
A program creation device having A central processing unit for executing the program;
Program storage means for storing an executable compressed file in which a plurality of files are combined as the program,
An embedded device that displays an error message when a problem is detected during program execution
A defect detection step for detecting a defect based on the stored contents of the address storing the execution result of the instruction;
When the defect detection means detects a defect, an error message including version information of the program, file identification information of the file, and a line number in the file of the instruction being executed is displayed in the instruction. An error message display step to output to the device;
A program that executes A file storage means for storing file designation information for designating a plurality of files and a file to be combined, and a program creation device for creating a single compressed file by combining a plurality of files;
A version information receiving step for receiving input of version information of the program;
An identification table creating step of creating a file identification table by giving file identification information to each of the plurality of files designated by the file designation information;
A predetermined symbol described in the file, the version information received by the version information receiving means, the file identification information of the file registered in the file identification table, and a line in which the symbol is described, or A symbol replacement step to replace with the line number of a nearby line,
A program that executes A program created by the program creation device according to claim 10,
A program characterized in that version information of the program, file identification information of the file, and line number in the file of an instruction being executed are described in a compressed file in which a plurality of files are combined.

Images