A memory leak will occur if the memory allocated by a module is not freed before that module returns its output(s). (See "Allocating and Freeing Memory" for a list of Objects that typically need freeing.) Typically, if there is a memory leak, Data Explorer runs for some time. Then, after allocating all available memory, it stops executing and generates an error message that it is out of memory. It can resume execution only after the server has been disconnected and restarted.
You can check a module for a memory leak by running it several times, together with the Usage module. If the memory managed by the executive is flushed after each execution, memory that is allocated by a module and not freed before returning will cause the Usage module to report an increase in memory. The following Data Explorer script checks for a leak:
macro showleak()
{
output = YourModule(input, ...);
Print(output);
}
·
(any modules necessary to produce input for your module)
·
showleak();
showleak();
Executive("flush cache");
Usage("memory", 0);
showleak();
Executive("flush cache");
Usage("memory", 0);
showleak();
Executive("flush cache");
Usage("memory", 0);
Each call to Usage prints out the amount of memory used in both the small and the large arena. Unless there is a memory leak in the module, these amounts will remain constant.
| Note: | It is important to run the executable in "readahead off"
mode.
The amounts reported by Usage will be distorted if the Data Explorer
executive reads the script ahead of execution.
Specify:
dx -exec your_directory/your_executable -readahead off -script |
[Data Explorer Home Page | Contact Data Explorer | Same document on Data Explorer Home Page ]