To turn on FaultFinder set the run-time tunable faultfind_level to a positive value. Then, if the application terminates abnormally, the run-time-system automatically invokes FaultFinder which in turn generates the report.
The following run-time tunables control the operation and output of FaultFinder:
| faultfind_config=n | Controls the inclusion of program memory data in the output file, where value indicates the action to perform and the type of memory as follows: 0 = Include all types of memory (default) 1 = Exclude working storage 2 = Exclude thread-local storage 4 = Exclude dynamically allocated memory These values can be combined to suppress combinations of types of memory, for example, a value of 5 will exclude working storage and dynamically allocated memory. |
| faultfind_level=n | Turns on FaultFinder and enables tracing of events. n can be any positive value less than or equal to 1024 and enables the last n events to be dumped. The default value is 0. |
| faultfind_outfile="filename" | The file to which the analysis is written. The default filename is fltfnd.out in the current working directory. If, for some reason, the specified file cannot be opened, output is directed to the screen. You can specify the filename as follows: "fault%option.log" Where option can be: d = replaced with the date of the fault in the format <yyyymmdd> p = replaced with the process ID of the faulting process t = replaced with the time of the fault in the format <hhmmss> |
| faultfind_recsize="record_size" | A numerecord_sizeric value, in bytes, that specifies the amount of extra data that is to be kept for each trace operation. record_size can be any non-negative value less than or equal to 1024. The default value is 64. |
Example:
set faultfind_config=5 set faultfind_level=5 set faultfind_outfile="applflt.log" set faultfind_recsize=1024
Enabling FaultFinder event tracing (that is, setting faultfind_level to a value greater than 0) does have a performance impact, although it should not be noticeable in most cases. The number of events traced does not significantly impact performance; tracing one event is not significantly faster than tracing 1000. The most expensive operations to trace are file operations; the worst case for FaultFinder is a file handling benchmark. Even if this is the case, you would expect no more than a 5% performance degradation. Most applications which perform a mixture of operations should see minimal impact on performance.