internal writes lead to creation of Windows mutex handles

[Andreas_Z_]

Hi,

After installing the Intel Visual Fortran Compiler 16.0 on Windows, I noticed that execution of internal write statements leads to Windows mutex handles being created for every internal write so that the number of process handles accumulates over the course of program execution (in my program to a great number). When using Intel(R) Visual Fortran Compiler 15.04, the number of handles does not increase for the same code/project.

Here is a test case that shows that reproduces on my system (Windows 7 x64). 

PROGRAM TestHandles1
    
    IMPLICIT NONE
    INTEGER(4) :: n
    CHARACTER(LEN=10) :: nchar, lchar
    !---------------------------------------
    DO n = 1, 100000
        WRITE(nchar,'(I0)') n
        WRITE(lchar,'(I0)') LEN_TRIM(nchar)
    ENDDO
    WRITE(*,*) "--> check number of process handles in Windows Task Manager"
    READ(*,*)
    
END PROGRAM TestHandles1

It does not seem to affect memory use, so I don't know if this is a bug or a feature - it seems harmless at this point. 

Best,
Andi

[Steven_L_Intel1]

Thanks. we'll check it out.

[Simon_Geard]

This could be what I'm seeing - see my latest post to 'IOSTAT 30 problems'.

[Steven_L_Intel1]

Not seeing it. I modified the program to print the handle count as it went, and double-checked it against the task manager count. No increase at all in handles as the program runs.

PROGRAM TestHandles1
    USE KERNEL32
    IMPLICIT NONE
    INTEGER(4) :: n
    CHARACTER(LEN=10) :: nchar, lchar
    INTEGER(DWORD) :: ret, StartHandles, CurHandles
    INTEGER(HANDLE) :: ThisProcess
    interface
    function GetProcessHandleCountX (hProcess, pdwHandleCount) BIND(C,NAME="GetProcessHandleCount")
      import
      integer(DWORD) :: GetProcessHandleCountX
      !DEC$ ATTRIBUTES STDCALL :: GetProcessHandleCountX
      integer(HANDLE), VALUE, INTENT(IN) :: hProcess
      integer(DWORD), INTENT(INOUT) :: pdwHandleCount
      end function GetProcessHandleCountX
    end interface
    
    ThisProcess = GetCurrentProcess()
    ret = GetProcessHandleCountX(ThisProcess, StartHandles)
    print *, StartHandles
    !---------------------------------------
    DO n = 1, 100000
        WRITE(nchar,'(I0)') n
        WRITE(lchar,'(I0)') LEN_TRIM(nchar)
        ret = GetProcessHandleCountX(ThisProcess, CurHandles)
        if (mod(n,1000) == 1) print *, CurHandles
    ENDDO
    WRITE(*,*) "--> check number of process handles in Windows Task Manager"
    READ(*,*)
    
END PROGRAM TestHandles1

C:\Projects>ifort U591225.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 16.0.0.105 Build 20150728
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 12.00.40629.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:U591225.exe
-subsystem:console
U591225.obj

C:\Projects>U591225.exe
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
           9
 --> check number of process handles in Windows Task Manager


C:\Projects>

[Andreas_Z_]

Thanks, Steve for checking this. I can now reproduce the results you got, but at first I got again the reported behavior of an increasing handle count.

This is why: I ran the modified test program both using Visual Studio 2015 and Visual Studio 2010 with Intel Visual Fortran Compiler 16.0 and got a result of increasing handle count independent of the VS version or whether I used 32 or 64 bit configurations. Then I went to project properties in Visual Studio (which I had left untouched / using default new project settings) and realized that the project was set with runtime library "Debug Multithread DLL". As soon as I set it to "Debug Multithreaded", I got the result of no increase in handle count, as reported by Steve. 

Some interesting points:

- This behavior was not found with the Intel Fortran Compiler 15.04 running the same VS solution (with "Debug Multithread DLL" set). 

- Can you reproduce the increasing handle count when using runtime library: "Debug Multithread DLL"?

- In my much larger program, where I noticed the high number of handles first, I still find an increasing handle count with Intel Visual Fortran Compiler 16.0 even though the project is set to use static multithreaded runtime library. So, it seems that the internal writes are not the culprit there. I will need to do some further testing (including checking a potential influence of OpenMP used in that program).

I would appreciate any ideas for testing likely candidates leading to a great number of handles being created (but not released?) on Windows 7.

Cheers,
Andi

[Steven_L_Intel1]

Ok, now I can reproduce the problem. One needs to build with the multithread library (which I wasn't doing from the command line before.) Makes sense. I will pass this on to the developers. Issue ID is DPD200375683.

[jvandeven]

I have been experiencing this problem as well (see thread here).  Unfortunately, this problem has not gone away in my case when alternative libraries are used...

[Stephen_Sutcliffe]

I've just encountered a similar problem where a huge number of Windows Handles are generated during read or write operations (Version 2016).  There comes a point where the application cannot read from the registry because of "insufficient resources" (Error 1450) when trying to create the key for the resource entry. Has the cause been identified yet and, other than reverting back to Version 2015, is there a workaround that can be adopted?

Thanks

[Kevin_D_Intel]

Thank you for notifying us about your instance. Unfortunately a root cause has not yet been identified for the earlier issue id that Steve noted he filed. I added your additional information to that issue id and requested Development notify us of any available work around as soon as possible.

[Stephen_Sutcliffe]

Thanks Kevin,

I am using Windows 7 and I can confirm that the problem goes away if I revert back to previous version of the compiler. Also of interest is that if I only relink (i.e. not recompiling everything) in older version the problem goes away also. Does this suggest the issue lies in one of the libraries that is link rather than the actual compilation?

I hope this helps.

[Kevin_D_Intel]

Thank you for the additional insight, I will pass that along.

Yes, your test helps confirm the issue is likely within the runtime libs and not the actual compiled code. You would not want to mix the newer compiled code (16.0) with the previous (15.0) runtime libs though as a temporary solution as that could lead to other problems. Your test just happened to not run into any issues in doing so.

[Steven_L_Intel1]

I am told that this problem will be fixed for 16.0.1 (2016 Update 1).

[van_der_merwe__ben]

This is not harmless, even READ statements are leaking "Mutant" handles and the system has a limit of about 16 million per process, after which all sorts of API and file function calls start to fail. If our code was doing this, we would rate it as a showstopper. I can only hope that Update 1 also fixed the mutant leaks in the READ statements. Will find out in the next day or two.

[Steven_L_Intel1]

Yes, this problem was fixed.