Consider this example of a file descriptor leak:
Purify indicates that 7 file descriptors are in use at the end of the program execution. Two of these are file descriptors opened by the program.
Look at the function get_number_from_file. These files are opened by the call to fopen, and should be closed by the call to fclose. Notice, however, that if the file does not contain a valid number, the function returns without closing the opened file. To correct this file descriptor leak, add a call to fclose before this return.
A safe FIU message shows the three standard I/O streams and the two Purify internal file descriptors. You do not need to be concerned with a few additional file descriptors open at exit, if they are allocated from functions called only once in the program.
If more than one file descriptor allocated with the same call chain is still open at exit, it can indicate a program error and you should investigate it. In the previous example, if the function get_number_from_file were called on a large number of files, the program could run out of file descriptors.
Purify's file descriptor data structures are shared across parent and child when the child is created using a vfork. If the child process manipulates files descriptors, it can result in erroneous messages about the origin of the parent's descriptors when the parent exits.
If you do not want Purify to display an FIU message when the program exits, set the option -fds-inuse-at-exit=no. This inhibits the call of purify_all_fds_inuse upon program exit.
Use the Purify API function purify_clear_fds_inuse to ignore file descriptors that have been opened since the last call to a file descriptor API function. These file descriptors are not reported by the next call to purify_new_fds_inuse. They will however be reported by purify_all_fds_inuse.
Note:
By default, Purify generates FIU messages before calling any cleanup functions you may have registered with atexit(3); therefore, Purify reports file descriptors closed by such functions as in-use.