JPH10269105A - Trace system, resource release omission detection system, and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To globally trace an OS(operating system) without recompiling it, and to effectively detect memory lead because of it even in a system which is made by combining components provided in binary. SOLUTION: A hooking DLL(dynamic link library) 2 hooks an API(application interface) call of an application part 1. The DLL 2 is inserted instead of an original DLL that corresponds to an API call. A processing DLL 3 executes processing that corresponds to the API call. The DLL 2 hooks a call of the part 1, sends the call information to a log filing part 4 and also transfers the call to the DLL 3. The part 4 logs the call information that is hooked by the DLL 2. A viewer 5 reads and shows log contents in the part 4.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a tracing system for performing global tracing of the entire system and a system for detecting omission of release of resources when developing or checking an application program, and more particularly to a system for detecting omission of resources. The present invention relates to a trace system and a resource release leak detection system suitable for performance tuning and effective detection of a memory leak.

[0002]

2. Description of the Related Art Operating systems (OS: Operat)
ing System, hereinafter referred to as an “OS”, an application program and a system program that operate on the OS, an application interface (API) of the OS.
Hereafter, memory allocation is performed using an “API”.

The memory allocated to a program is released when the memory becomes unnecessary. In general, resources such as memory are limited, and if the used memory is not released, the amount of available memory decreases and the program cannot be executed normally.
However, due to a defect in the program, the memory once allocated may not be released even when it becomes unnecessary. Leaving the memory that has become unnecessary without releasing it in this way is referred to as a memory leak (memory release omission). If this memory leak is left, as described above, the amount of available memory is reduced, and the program cannot be executed normally.

[0004]

The larger the system, the greater the likelihood that the aforementioned memory leak will occur. On the other hand, the smaller the memory leak itself, the more likely it is to be overlooked in various check steps in development. In this way, if a memory leak is overlooked during the development process, the final confirmation phase of the system,
That is, in a continuous operation test, it is finally discovered. In addition, the only way to determine where in the program the memory leak is occurring is through a method such as source review.

In particular, an OS such as Windows NT (Windows NT) and Windows 95 (Windows 95) ("Windows" is a registered trademark) is composed of a plurality of processes.
OLE control (hereinafter, “OCX”), which is an OLE server object using the “OLE”) function, and a dynamic link library (hereinafter, “DLL”)
Etc. are included. OCX has recently been
It is positioned as a component called Active X control.

[0006] In such an OS, resources are managed only on a process-by-process basis. Therefore, even if there is a problem with a DLL or OCX belonging to a process, it is impossible to isolate them. Therefore, in some cases, it is necessary to investigate the cause of the memory leak over the entire system.

[0007] As described above, once a memory leak occurs in the development of an application program and a system program, an enormous amount of time is often spent for solving the problem.

Normally, when tracing a program for the purpose of detecting a memory leak or the like, a special object (here, an object indicates an object in an OBJ file or C ++) is linked. Use a method. Therefore, in order to trace the program, it is necessary to compile and link from the source code again. However, in this method, OCX and ActiveX widely used recently are used.
In software created by combining components provided in binary, such as a control, only incomplete information is given and cannot be used effectively.

The present invention has been made in view of the above circumstances, and has as its object to enable effective detection of a memory leak.

[0010]

To achieve the above object, a trace system according to a first aspect of the present invention comprises:
An operating system having an application interface for interfacing with an application program; application means for executing the application program on the operating system; and execution of the application program by the application means. It is characterized by comprising hook means for relaying the call and taking in the information of the call, and log recording means for accumulating and recording the information taken in by the hook means.

According to this system, the application program (AP) is operated by the operating system (O).
When the application interface (API) of S) is called, the hook means takes in the information of this call, and the log recording means records the contents. So, for example, an application interface call
In the case of resource allocation and release, for example, memory, allocation and release history is automatically generated by the log recording means. Therefore, by discriminating a pair of resource allocation and release, and determining from the log what has been allocated but not released, it is possible to determine that the resource has been left unreleased. Further, according to such a configuration, it is possible to acquire the call information without substantially changing the application program and the operating system.

Examples of the resource leak include a file resource, an exclusive resource such as a semaphore and a Mutex, and a leak of a GDI object such as a pen, a brush, and a device context.

The hook means includes, for example, means for receiving a call of an application program for the application interface in place of the application interface, means for providing the call information to the log recording means, and means for transmitting the call to the application interface. Means for transferring to

[0014] A means for outputting the information of the call recorded by the log recording means may be arranged.

[0015] Logging control means for controlling on / off of recording of information transferred from the hook means to the log recording means may be arranged. The logging control means controls the suspension and execution of the transfer of the call to the application interface by the hook means in response to, for example, an external operation.

[0016] The logging control means may include means for controlling the contents of the information recorded in the log recording means.

The hook means fetches, for example, resource allocation information relating to the resource allocation of the operating system in the call of the application interface by the application program. Further, the log recording means detects a pair of recorded resource allocation and release, detects only one of the allocation and release, and when the other can not be detected,
A pair detection means for notifying that may be provided so that a release omission of resources can be notified.

In order to achieve the above object, a second aspect of the present invention is provided.
A resource release omission detection system according to the aspect of the present invention comprises: an application unit that executes an application program on an operating system; and a request for allocating and releasing resources transmitted from the application program to an application interface of the operating system when the application program is executed. And a log recording unit for accumulating and recording the resource allocation information captured by the hook unit.

A pair detecting means for detecting a pair of resource allocation and release recorded by the log recording means, detecting only one of the allocation and release and detecting the other when the other cannot be detected, is arranged. Is also good.

According to such a system, the operating system and the application program detect the call of the application interface without substantially affecting them, and store the history of resource allocation and release based on the call information. Can be taken to the log. Therefore, by checking this log, it is possible to determine whether to release the resources. Resources include, for example, file resources, semaphores, and Mute
There are exclusive resources such as x, GDI objects such as pens, brushes, and device contexts.

A pair detecting means for detecting a pair of resource allocation and release recorded by the log recording means, detecting one of the allocation and release, and not detecting the other when the other cannot be detected, is arranged. Alternatively, a resource release omission may be automatically detected. A memory or the like is suitable as a resource.

A computer-readable recording medium according to a third aspect of the present invention includes an application for executing an application program on an operating system having an application interface for interfacing with the application program. Means for relaying a call of the application interface by the application program when the application program is executed by the application means, and for storing the call information fetched by the hook means, and storing the call information fetched by the hook means A program (including fixed data) for functioning as a log recording means for recording is recorded.

A computer-readable recording medium according to a fourth aspect of the present invention includes: an application unit for executing an application program on an operating system; and an application program for executing the application program. A program for functioning as hook means for capturing resource allocation information relating to resource allocation and release requests sent to the application interface of the operating system, and log recording means for storing and recording the resource allocation information captured by the hook means. Is recorded.

[0024]

DESCRIPTION OF THE PREFERRED EMBODIMENTS A trace system according to a first embodiment of the present invention will be described with reference to FIGS.

This embodiment uses Windows NT, Windows 95, or the like as an operating system (OS), and a system call in these OSs is a dynamic link library (Dynamic Link Library).
rary: DLL-hereinafter, referred to as "DLL"), and replaces the DLL with a special hook hook DLL. This hook DLL allows all application interfaces (Application Program Interface)
rface: An API (hereinafter referred to as “API”) is intercepted, that is, hooked, and the API caller and the time are logged.

A log file created by logging is read when necessary, and is visually displayed by a viewer. By doing so, O
By realizing a global trace of S, it is possible to obtain information, such as for each process and each module, necessary for system optimization. Further, by tracking the allocation status regarding the allocation of OS resources such as memory allocation and handle allocation, it is possible to effectively analyze and display the location where the memory leak has occurred. This system also enables automatic analysis and display of memory leaks.

In addition to the memory, it is possible to trace leaks of exclusive resources such as file resources, semaphores and mutexes, and GDI objects such as pens, brushes and device contexts.

FIG. 1 shows a configuration of a trace system according to a first embodiment of the present invention.

The trace system shown in FIG. 1 comprises an application section 1, a first hook DLL 2, a first processing DLL 3, a log file section 4, a viewer 5, a second hook DLL 6, and a second processing DLL 7. , And a control manager 8. Application unit 1, first hook DLL 2, first processing DLL 3,
Viewer 5, DLL 6 for second hook, D for second processing
Each part of the LL 7 and the control manager 8 is configured by a program module as a component. The log file unit 4 is composed of files stored in a storage device.

The application section 1 executes an application program (AP) on an OS (operating system). This application unit 1 and OS
Is an application interface (API). The OS system call is DLL
Interface with the application unit 1.

The first hook DLL 2 is a DLL for hooking (preempting) an API call of the application unit 1 and an original DLL corresponding to the API call.
Inserted instead of L.

The first processing DLL 3 is an original DLL corresponding to an API call of the application unit 1, constitutes a part of the OS, and executes processing corresponding to the corresponding API call.

The first hook DLL 2 hooks a call to the original DLL (first processing DLL 3) of the application unit 1, transmits information of the call to the log file unit 4, and transfers the call to the log file unit 4. 1 to the processing DLL 3. The log file unit 4 logs the call information hooked by the first hook DLL 2 or the like, that is, records and accumulates the call information.

The viewer 5 reads and displays the log contents of the log file unit 4. Since the viewer 5 itself is also a kind of application, when using the API, the second processing DLL 6 via the second hook DLL 6 is used.
Call LL7. The second hook DLL 6 hooks this call and sends information of the call to the log file unit 4.

The control manager 8 has a hook D
LL2 and LL6 are controlled and managed. By operating the control manager 8 externally, on / off of the hook of the call information, selection of the setting of the call information to be hooked, and the stop (go) / go (continue) of the transfer operation of the call to the processing DLLs 3 and 7 are performed. Can be controlled.

With reference to the flowchart of FIG. 2, the flow of processing when installing the trace system will be described.

When installation is started, first, a processing DLL to which the trace system is to be applied, for example, processing DLLs 3 and 7, is searched (step S1). When the processing DLLs 3 and 7 are searched, the searched processing D
The original file names of LL3 and LL7 are renamed to other dummy file names (step S2).

Next, the hook DLLs 2 and 6 are introduced into the system with the original file name of the processing DLL renamed earlier (step S3). Then, a log file viewer for referring to the log file is incorporated into the system (step S4), and a control manager 8 for controlling the hook DLLs 2 and 6 is incorporated into the system (step S5).

In the processing described above, a Windows NT system of Microsoft Corporation is used as the OS, and the DLL hook system of the trace system is referred to as a virus system (VIRUS system).

In this case, the DLL hooked by the virus system is a 32-bit graphic device interface (GDI), hereinafter referred to as “G”.
GDI32.DI). DLL,
USER32.32 which is a DLL for 32-bit users. DL
L, DLL for DLL processing for Windows NT. DLL and DLL for 32-bit OLE
OLE32. DLL for 32-bit Windows (hereinafter referred to as "WIN3
2DLL ”). DLL, U
SER32. DLL and NTDLL. DLL.

The GDI 32. DLL, USER3
2. DLL and NTDLL. DLLs can be used to detect memory leaks. By the way, these GD
I32. DLL, USER32. DLL and NTDL
L. DLL can also be used for global tracing in a basic 32-bit Windows system, and OLE32. DLLs can only be used for global tracing.

FIG. 3 shows the GDI 32. 4 shows a module configuration related to DLL, and FIG. 2 shows a module configuration related to DLL.

At the time of installation, the Virus system uses the default WIN32. GDI32.DLL. DLL
First, the above three DLL files are stored in another dummy file name, for example, GDI32. DLL to VIRU
SGDI. Rename to DLL.

Next, a DLL for a virus system having a logging mechanism using hooks, that is, a DLL for hooks
With GDI32. DLL that was introduced into the system and renamed earlier. Replace with DLL. This hook DLL is GDI32. It has the same external interface and parameter configuration as the DLL, but is created to log information on API calls to the log file unit 4 for a specific API set in advance. In other words, the application program
The original processing DLL GDI32. It operates as if it were linked to the DLL, but is actually linked to the hook DLL of the viral system.
The DLL for the hook of the Virus system is V
IRUSGDI. DLL as the original GDI 32. D
Call LL and provide the required information. In this way, the GDI call information is hooked.

The GDI 32. DLL, USER3
2. DLL and NTDLL. Normal DL like DLL
In L, an entity object that is a processing entity exists in the DLL itself. Therefore, when these DLLs are called from an application program, a log mechanism for easily logging can be constructed by hooking only the entry point.

Next, the operation when the application program is executed will be described with reference to the flowchart shown in FIG. When the application is executed in the application unit 1, the application executes A if necessary.
A PI call is made (step S11). This API call is hooked by the first hook DLL 2 (step S12). The first hook DLL 2 logs information of the hooked call in a log file (step S13). The first hook DLL 2 calls the original first processing DLL 3 in response to the call from the application unit 1 (step S14). The first processing DLL 3 performs the corresponding API processing (step S
15).

It is determined whether or not the execution of the application program has been completed (step S16). During the execution of the application program, the above-described steps S11 to S15 are repeated for each API call.
In this way, API call information is logged,
The log file section 4 records the history of the API call information, that is, a log.

That is, in the Virus system, the API
At the time of calling and at the time of return after processing, a logging process is performed, and the called module name, address, time, performance count value, and the like are recorded in the log file unit 4. In this way, the processing time from a certain point to a certain point can be measured. In this case, unlike the normal local measurement, since the OS library is replaced, there is no need to change the module to be measured at all. By doing so, a bottleneck in the processing time can be easily checked.

Further, the detection of a resource release omission such as a memory leak is performed by using such a trace system as shown in FIG.
As shown in (1), it is realized in combination with the analysis unit 9. The analysis unit 9 can be implemented by software, for example, by adding a function to a conventional fuser. The analysis unit 9 traces the contents of the log recorded in the log file unit 4 and allocates and releases memory. Detect name pairs, list unassigned and unassigned modules, display them, and issue warnings.

That is, a memory leak occurs when the memory is not released even though the memory allocation is called. Therefore, the log can be traced by focusing on the module name, and the module can be discriminated by listing the modules that are not paired and released. In rare cases, the module that allocates the memory and the module that releases the memory may be different. However, by tracing the release address and the handle value and displaying them, correct leak information can be displayed. If the release and the allocation are separate, it is output as warning information because it may be a bug of the program in rare cases.

In this manner, the call of the API of the OS such as Windows NT or Windows 95 can be hooked by the hook DLLs 2 and 6, and the caller and time of the API can be logged. By visually displaying the log file unit 4 with a viewer, a global trace of the OS can be realized, and information necessary for system optimization, such as for each process and each module, can be obtained. Based on this information, performance tuning of the system can be realized. In addition, by tracking the allocation status of OS resources such as memory allocation and handle allocation, it is possible to effectively analyze and display a location where a memory leak has occurred. By using this system, automatic analysis and display of a memory leak can be realized.

FIG. 7 shows a configuration of a trace system according to a second embodiment of the present invention. FIG.
A trace system in which a processing object is not embedded in the processing DLL itself, but is linked to another entity module, and includes an entity that calls the entity module and performs processing, such as the E interface. Is shown.

The trace system shown in FIG. 7 includes an application section 11, a first hook DLL 12, a first processing DLL 13, a substantial module 14, a log file section 4,
Viewer 5, DLL 6 for second hook, D for second processing
An LL 7 and a control manager 8 are provided.

The application section 11, the first hook DLL 12, and the first processing DLL 13 are substantially the same as the application section 1, the first hook DLL 2, and the first processing DLL 3 of FIG. DL for processing 1
L13 calls the entity module 14 to execute the processing. That is, the first processing DLL 13 is provided with the first processing DLL for some or all of its interfaces.
The process is executed by the entity module 14 without executing the process by the L13 itself.

If the first hook DLL 12 is not inserted, the first processing DLL 13 returns the entry point of the entity module 14 to the application unit 11 at the first call, and thereafter, the application unit 1
From 1, the entity module 14 is called directly. Therefore, the first hook DLL 12 is provided by the entity module 14.
, The entry point of the first hook DLL 12 is returned as a dummy entry point. In this way, every time the application unit 11 calls the interface, the entity module 14 is called through the first hook DLL 12. Therefore, logging can be performed immediately before the calling of the entity module 14.

The log file unit 4, viewer 5, DLL for second hook 6, DLL for second processing 7, and control manager 8 are the same as those in FIG. Application unit 11, first hook DLL1
2. DLL for first processing 13, entity module 14, viewer 5, DLL for second hook 6, DL for second processing
Each part of the L7 and the control manager 8 is configured by a program module as a component. The log file unit 4 is composed of files stored in a storage device.

In the case where the first processing DLL 13 executes the processing by itself without depending on the actual module 14, the first hook DLL 12 and the first processing DLL
The function and operation of L13 are exactly the same as those of the first hook DLL 2 and the first processing DLL 3 in FIG.

Next, the execution operation of the application of the trace system of FIG. 7 will be specifically described. The installation of the trace system of FIG. 7 is performed in accordance with the flow shown in FIG. 2, similarly to the system of FIG.

As described above, for example, the OLE module OLE23. In the case of DLL, normal DLL
Performs a slightly special operation compared to. That is, OLE is D
Although implemented by LL, the interface is different from that of a normal DLL. OLE32. When called from the application program, the DLL calls the entity module 14 which is a processing entity, and causes the entity module 14 to execute a process. Therefore, it is necessary to devise a log mechanism for logging.

As described above, when a normal DLL is called from an application program executed by the application unit 11, the processing entity exists in the DLL itself, and only the entry point is hooked. Can be easily logged.

However, in the OLE interface, the first call passes through the OLE DLL, but returns the pointer of the physical module. Therefore, the subsequent calls are performed by the physical module without passing through the DLL from the application program. It is.

In the OLE interface, it is not sufficient to simply hook the OLE DLL.
In the first hook DLL 12, as a pointer:
It returns the dummy interface, that is, the entry point of the first hook DLL 12 which is the DLL of the virus system. By causing the first hook DLL 12 to call the entity module 14, logging or the like can be performed immediately before calling the entity module 14.

Next, referring to the flowchart shown in FIG. 8, the operation at the time of executing the application will be described. When the application is executed by the application unit 11, an API call is made (step S2).
1). The API call is hooked by the first hook DLL 12 (step S22), and information of the hooked call is logged in the log file unit 4 (step S22).
23). The first hook DLL 12 responds to a call from the application unit 11 and the first processing DLL 1
3 is called (step S24), and it is determined whether or not the call is the OLE interface (step S25).
If not OLE, in the first processing DLL 13,
The corresponding API processing is performed (step S26).

Thereafter, it is determined whether or not the execution of the application program in the application section 11 has been completed (step S27). In step S25, O
If it is determined that the interface is the LE interface, the entry point is converted by the first hook DLL 12 (step S28), and the entity module 14 is called. The corresponding API processing is performed in the entity module 14 (step S29), and the process proceeds to step S27. Once the entry conversion is performed in step S28, after logging in step S23, the first hook DLL 12
Therefore, the entity module 14 may be directly called without calling the first processing DLL 13 each time.

According to the determination in step S27, during execution of the application program, the above-described steps S21 to S26 or S21 to S25 → S
The processing of 28 → S29 is repeated. In this way,
API call information is logged and the log file part 4
The history of the API call information, that is, a log, is recorded in the log.

In FIG. 8, in step S25, it is determined whether or not OLE is selected.
When replacing OLE, OLE is embedded in the logic of the dummy DLL (created for logging acquisition, not attached to the OS) so that it is not determined whether or not the OLE is used. Is also good.

The case of the above-mentioned OLE module will be described in more detail. As mentioned above, OLE is D
Although implemented by LL, the interface is slightly different from that of a normal DLL. As shown in FIG.
When L is called from the application program AP, the processing entity exists in the DLL itself. If only the entry point is hooked, it is easy to insert a log mechanism or the like.

However, as shown in FIG. 9, in the OLE interface, the first call passes through the OLE DLL, but it returns a pointer to the entry of the substantial module. The entity module is called without going through the DLL. Therefore, in the OLE interface, it is not sufficient to simply hook the OLE DLL with the DLL for the hook, and as shown in FIG. 10, a dummy interface, that is, the DLL (hook) of the viral system is used as the pointer of the entry. DLL) entry point. By calling the entity module by the pointer, it is possible to perform logging or the like immediately before calling the entity module.

That is, the OLE interface (OLE interface) is similar to the C ++ implementation in that
After creating a pointer with CreateInstance, each interface is called based on this pointer. In the Virus system, the first CoCreateInstance uses the hook of the DLL interface to execute the original OLE 32. DLL is called, and the object pointer returned at this time is set to OLE32. Return to a dummy pointer of its own instead of the pointer returned by the DLL. Then, the application that has called the OLE treats the dummy pointer as an original pointer, so that the next time the object is called, the object is called based on the dummy pointer. This pointer is a pointer issued by the virus system. Every time an application calls an object, the pointer can be hooked by the virus system, and after performing one kind of logging operation, the original OLE 32. Call the pointer returned by the DLL. These points are points where the operation is different from that of a normal DLL.

As already mentioned, the Virus system is:
Logging processing is performed at the time of calling the API and at the time of return after the processing is completed, and the called module name, address, time, performance count value, and the like are recorded in a log file. In this way, the processing time from a certain point to a certain point can be measured. Unlike ordinary local measurement, since the OS library is replaced, there is no need to change the module to be measured at all. In addition, FIG.
As shown in (1), this mechanism and the analysis unit 9 are used in combination.

The trace system shown in FIGS. 1 and 7 will be described more specifically. This system is mainly composed of component modules as shown in FIG.

FIG. 11 shows GAP. EXE, GAPUI.
DLL, GAPUI. OCX, FSENGINE. DL
L, VRSCTRL. EXE, NOSIDEIF. DL
L, VIRUSTUB. DLL and VIRUSLOG.
4 shows each module of the DLL.

GAP. EXE is an execution module of the viewer and corresponds to the viewer 5. GAPUI. DL
L is GAP. EXE specific interface DLL,
GAPUI. OCX is available from GAP. OCX for EXE (O
LE control) 21.

VRSCTRL. EXE is an execution module of the control manager, and corresponds to the control manager 8. VIRSTUB. DLL and V
IRUSLOG. DLL is API of Virus System
DLLs for hooking call information, which correspond to the hook DLLs 2, 6, or 12. GAPU
I. DLL, FSENGINE. DLL and NOSID
EIF. The DLL is a DLL for executing various types of processing, and corresponds to the processing DLL 3, 7, or 13.

The components shown in FIG. 11 mainly provide the following four services. (1) Current information acquisition service Obtains monitoring information of the current allocation of GDI objects and monitoring information of the issuance status of API calls such as OLE and GDI from at least one of the logging buffer and the log file unit 4 and obtains the viewer 5 GAP.
Display by EXE. The monitoring information on the assignment of the GDI object includes information on the assignment and release of the resource and the owner.

(2) Logging Service Some interfaces of DLL for GDI and OLE are described in VIRSTUB. Apply the DLL patch. Specifically, as described above, the original processing DLL is renamed at the time of installation, and instead, the dummy DLL for hook is used as the file name of the processing DLL.
Insert

In this way, every time a required interface is called, the interface goes through the DLL of VIRUS, and the call, the assignment of the object, and the release status can all be grasped. With this feature,
The logging mechanism can be set on / off for each DLL and execution program (hereinafter referred to as “EXE”), and the logging level can also be set to three levels, for example, 0 = OFF, 1 = call only, and 2 = call and parameters. Can be set to Information acquired in a log file or the like by logging can be displayed on a fuser.

(3) Dynamic Execution Service This service is realized by using a logging service. When an application program calls OLE and GDI, VRS which is the control manager 8
Stop / go can be instructed by instructions from CTRL and EXE. This function is used when confirming call parameters and displaying OLE internal information and GDI resource allocation status without going through a debugger.

(4) Debugging library service A programming language such as Visual BASIC (Visual
A debug support library is provided for developers such as Basic: VB).

The basic operation is as follows. DLLs for APIs that are supported as standard in Windows NT and Windows 95, etc., are provided by VIRUSTUB. Replace with DLL. This DLL
Defines only the entry points for all standard interfaces. On the other hand, the existing DLL is renamed.

The API call from the application goes not through the existing library but through the DLL of the replaced virus system. On the other hand, the renamed existing DLL includes the function of the original API, so that after logging, the library is called. After the original processing, the processing returns to the DLL of the virus system again. If the time during the processing is logged, the processing time and the like can be grasped.

Also, in the resource allocation, since there are calls for reservation and release, when they are not paired, it is determined that a leak has occurred, and a warning is given by the viewer. A resource can be specified by a module name, a handle value, an address, and the like.

In this manner, the API call in the OS such as Windows NT or Windows 95 can be hooked by the hook DLLs 12 and 6 to log the API caller and the time. By visually displaying the log file unit 4 with the viewer 5, a global trace of the OS can be realized, and information necessary for system optimization, such as for each process and each module, can be obtained. Moreover, operations such as recompilation and relinking are not required.

The above-described trace system can be realized by using a general computer system without using a dedicated system. For example, by installing the program from a medium (a floppy disk, a CD-ROM, or the like) on which a program for executing the above-described operation is recorded in a computer, a system that executes the above-described processing can be configured.

Further, the medium for supplying the program to the computer may be a communication medium (a medium that temporarily and dynamically holds the program, such as a communication line, a communication network, or a communication system). For example, the program may be posted on a bulletin board (BBS) of a communication network and distributed via the network. Then, by starting this program and executing it in the same manner as other application programs under the control of the OS, the above-described processing can be executed.

When the OS takes part of the functions of the above-mentioned system, or when the OS and the application program cooperate to achieve some or all of the above-mentioned functions, the recording medium contains the OS. Other program portions or data portions may be stored.

[0087]

As described above, in the trace system and the memory leak detection system according to the present invention, every time an interface of an application program is called, call information and resource allocation information relating to the call are hooked and recorded. Effective detection of resource release omissions such as global trace of the operating system and memory leaks can be performed. That is, in the present invention, recompilation is unnecessary,
Even in a system created by combining components provided in binary, it is possible to globally trace the OS and effectively detect memory leaks thereby, and to perform system performance tuning including memory leak detection and resolution A trace system and a memory leak detection system that can be used effectively can be provided.

[Brief description of the drawings]

FIG. 1 is a block diagram schematically showing a configuration of a trace system according to a first embodiment of the present invention.

FIG. 2 is a flowchart for explaining an installation operation in the trace system of FIG. 1;

FIG. 3 is a schematic diagram for explaining an operation principle of a DLL of the trace system of FIG. 1;

FIG. 4 is a schematic diagram for explaining the principle of a hook of the trace system of FIG. 1;

FIG. 5 is a flowchart illustrating an operation of executing an application program in the trace system of FIG. 1;

FIG. 6 is a block diagram showing a configuration of a system for detecting a resource release omission such as a memory leak.

FIG. 7 is a block diagram schematically showing a configuration of a trace system according to a second embodiment of the present invention.

FIG. 8 is a flowchart illustrating an operation of executing an application program in the trace system of FIG. 7;

FIG. 9 shows a normal DLL of the trace system of FIG.
FIG. 4 is a schematic diagram for explaining the operation principle of the DLL of the LE.

FIG. 10 is a schematic diagram for explaining the principle of the DLL hook of the OLE of the trace system of FIG. 7;

FIG. 11 is a schematic diagram showing an example of a specific module configuration in the trace system of FIGS. 1 and 7;

[Explanation of symbols]

1,11 Application section 2,6,12 Hook dynamic link library (DLL) 3,7,13 Processing dynamic link library (DLL) 4 Log file section 5 Viewer 8 Control manager 14 Real module

Claims (13)

[Claims] An operating system having an application interface for interfacing with an application program; an application means for executing the application program on the operating system; and an application program for executing the application program by the application means. And a log recording means for storing and recording the information of the call fetched by the hook means while relaying the call of the application interface according to the above. system. 2. The information processing apparatus according to claim 2, wherein said hook means receives a call of an application program for said application interface in place of said application interface, provides said log information to said log recording means, and transmits said call to said application interface. 2. A trace system according to claim 1, further comprising: 3. The trace system according to claim 1, further comprising means for outputting the information of the call recorded by the log recording means. 4. The apparatus according to claim 1, further comprising logging control means for controlling on / off of recording of information transferred from said hook means to said log recording means. Trace system described in 1. 5. The apparatus according to claim 1, wherein said logging control means further comprises means for controlling a stop and execution of transfer of said information from said hook means to said application interface in response to an external operation. 5. The trace system according to 4. 6. The trace system according to claim 4, wherein said logging control means further includes means for controlling the contents of said information recorded in said log recording means. 7. The apparatus according to claim 1, wherein said hook means includes means for taking in resource allocation information relating to resource allocation of said operating system among calls of said application interface by said application program. The trace system according to claim 1. 8. A pair detecting means for detecting a pair of recorded resource allocation and release by the log recording means, detecting only one of the allocation and release, and notifying the fact when the other cannot be detected. The trace system according to claim 7, further comprising: 9. Application means for executing an application program on an operating system; and resource allocation information on resource allocation and release requests sent from the application program to an application interface of the operating system when executing the application program. A resource release omission detection system, comprising: hook means for taking in; and log recording means for storing and recording the resource allocation information taken in by the hook means. 10. A pair detecting means for detecting a pair of resource allocation and release recorded by the log recording means, detecting only one of the allocation and release, and notifying the fact when the other cannot be detected. The resource release omission detection system according to claim 9, comprising: 11. The resource release omission detection system according to claim 9, wherein the resource is a memory. 12. An application unit for executing an application program on an operating system having an application interface for interfacing with an application program, wherein the application unit executes the application program by the application unit. A computer that records a program for functioning as a hook unit that relays the call of the interface and captures the information of the call, and a log recording unit that stores and records the information of the call captured by the hook unit. Recording medium. 13. An application means for executing an application program on an operating system, comprising: a computer for executing an application program; and resource allocation relating to a request for allocation and release of a resource sent from the application program to an application interface of the operating system when the application program is executed. A computer-readable recording medium storing a program for functioning as hook means for taking in information, and log recording means for storing and recording the resource allocation information taken in by the hook means.