- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I ran "Memory Error Analysis / Detect Leaks" on my Fortran code (fixed form) and Inspector reported several problems that I don't understand:
1. Kernel resource leak in the following piece of code:
use ifport
character*1024 arg0
character*1024 filename
character*16 dllname
character(3) drive
character(256) dir, name, ext, file
integer*4 length
integer (kind=int_ptr_kind()) handle
type (file$info) info
call getarg ( 0, arg0 )
length = SPLITPATHQQ ( arg0, drive, dir, name, ext )
dllName = 'myDLL.dll'
filename = drive(1:len_trim(drive)) // dir(1:len_trim(dir)) // trim(dllName)
handle = FILE$FIRST
if ( GETFILEINFOQQ(filename, info, handle) .gt. 0 ) then
...
endif
The kernel resource leak is reported for the line with the function GETFILEINFOQQ; I wonder what I am doing wrong. Is it the size of filename, being character*1024 ?
2. Memory leak or Uninitialized partial memory access in the last line of the code
use ifport
integer(2) status
status = DELFILESQQ('myFile.dat')
By the way, the example in the documentation for the function DELFILESQQ declares the results of the function as integer(4), could this be any problem that integer(2) as the results of the function is assigned to integer(4) variable?
3. Invalid partial memory access or Uninitialized partial memory access in multiple locations:
integer*4 iunx_ew, iunx, ios, iocheck, rcl
character*20 file_ew_text, finame
OPEN ( iunx_ew, FILE=file_ew_text, ACCESS='SEQUENTIAL', ACTION='WRITE', SHARE='DENYWR', IOSTAT=ios )
OPEN ( 99, FILE='myDB.d', ACCESS='DIRECT', STATUS='OLD', RECL=520, IOSTAT=iocheck, SHARE='DENYWR' )
OPEN ( iunx, FILE=finame, ACCESS='DIRECT', RECL=rcl, IOSTAT=iocheck, SHARE='DENYWR' )
All the lines with the OPEN statement exhibit the memory access problem. Why?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. From the documentation for GETFILEINFOQQ:
"GETFILEINFOQQ must be called with the handle until GETFILEINFOQQ sets handle to FILE$LAST, or system resources may be lost"
2. This looks like it occurs inside the implementation of DELFILESQQ. This is a false positive and can be ignored.
3. Assuming the file name and unit number variables are defined, these are false positives occuring inside OPEN, and can be ignored.
You can use the suppression feature to remove future reporting of these problems.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The proper coding of GETFILEINFOQQ based on the documentation helped me to get rid of the memory error. Thank you!
I will be looking at the suppression feature later; I don't have so many false positives in my application.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page