DGGEV routine returns with heap corruption error

[GoldenRetriever]

The DGGEV routine works fine if noeigenvectors required, howeverwhen I request the left or righteigenvectors to be computed, the errors come up for any ALLOCATE orDEALLOCATE in the nextcommands. Such as:

"Windows has triggered a breakpoint in DGGEV.exe.

This may be due to a corruption of the heap, which indicates a bug in DGGEV.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while DGGEV.exe has focus.

The output window may have more diagnostic information."

If I press continue, another error message comes up:

"Unhandled exception at 0x77b635e3 in DGGEV.exe: 0xC0000374: A heap has been corrupted"

Message at call stack window: [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]ntdll.dll!77b635e3()

Attached is the sample code. Anyone know solution for this please advise.

System: Windows 7, MVS2010,Composer XE 2011 SP1

[bash]      INCLUDE 'link_fnl_static.h'
      !DEC$ OBJCOMMENT LIB:'libiomp5md.lib'
      USE IMSL_LIBRARIES
      USE MKL95_LAPACK
      IMPLICIT   NONE
      INTEGER    N, LWORK, INFO
      PARAMETER  (N=4)
!
      DOUBLE PRECISION A(N,N), B(N,N), WORK_TMP(N), ALPHAR(N), ALPHAI(N), BETAR(N), VCL(N,N), VCR(N,N), EVAL(N)
      INTEGER, ALLOCATABLE, DIMENSION(:) ::    WORKR, TEST
!
!                                 Define values of A and B:
!                                 A = ( 0.24    0.39    0.42    0       )
!                                     ( 0.39    -0.11   0.39    0.63    )
!                                     ( 0.42	0.39	-0.25	0.48    )
!                                     ( 0       0.63	0.48	-0.03   )
!
!                                 B = ( 2.07	0.95	0	    0       )
!                                     ( 0.95	1.69	-0.29	0       )
!                                     ( 0	    -0.29	0.65	-0.33   )
!                                     ( 0	    0	    -0.33	1.17    )
!
!                                 Declare variables

      DATA A/0.240D0,0.390D0,0.420D0,00D0, 0.390D0,-0.110D0,0.390D0,0.630D0, 0.420D0,0.390D0,-0.250D0,0.480D0, 00D0,0.630D0,0.480D0,-0.030D0/
      DATA B/2.070D0,0.950D0,00D0,00D0, 0.950D0,1.690D0,-0.290D0,00D0, 00D0,-0.290D0,0.650D0,-0.330D0, 00D0,00D0,-0.330D0,1.170D0/

!                                 Compute eigenvalues

        CALL DGGEV("N", "N", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORK_TMP,-1, INFO)    
        LWORK = WORK_TMP(1)
        ALLOCATE(WORKR(LWORK))
!        CALL DGGEV("N", "N", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORKR, LWORK, INFO) !Work with this. Both "N"
        CALL DGGEV("N", "V", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORKR, LWORK, INFO)  !Not work when change to "V" to get right generalized eigenvectors
        EVAL = (ALPHAR+ALPHAI)/BETAR
        ALLOCATE(TEST(N))
        DEALLOCATE(TEST)
      END[/bash]

[mecej4 · Accepted solution]

The work array WORKR is required to be of type DOUBLE PRECISION. In effect, then, you allocated only 1/2 the required work space.

It is wrong to assume that querying for the required size for the 'N','N' case with -1 in place of LWORK will give the correct size required for calling with 'V,'V'. The latter case asks for more results (eigenvectors) and, presumably, could be expected to need more workspace.

Once the call to Lapack is made with too small a work array, the program will be in a corrupted state and any later runtime errors will be off the mark.

If you want to use the F77 calls to MKL/LAPACK, you do not need the USE MKL ... statement(s). Likewise, since your example does not need IMSL, the INCLUDE and USE statements for IMSL are not needed.

The F95 call would be much simpler, since you would not need to do allocate the work space:

CALL GGEV(A,B,ALPHAR,ALPHAI,BETAR,VCL,VCR)

[GoldenRetriever]

Some USE MKL.. IMSL.. remained there as I used the same file to try different solvers sometime.

I got the interface checking option turned on but the compiler does not pick the real problem in this case. I remember in some cases I met before the compiler could pick up if there is any inconsitent in type ofarguments.

Thanks for pointing out the problem and the F95 caller as well.

Great help mecej4..

Cheers

[mecej4]

The compiler would not be able to pick up this error without a little help from you. The interface checking does not do the job since it has no access to the MKL source code.

The MKL interfaces for use in Fortran 77 callers are in the include file mkl_lapack.fi. However, that file is in Fortran fixed format, so to include it successfully in your free-format source, you have to do the following:

[fxfortran]      !DEC$NOFREEFORM
      !DEC$FIXEDFORMLINESIZE:132
      
      IMPLICIT   NONE          ! <=== you have this already

      include 'mkl_lapack.fi'
      !DEC$FREEFORM
[/fxfortran]

With these changes, the compiler gives this error:

[bash]xdggev.f90(43): error #6633: The type of the actual argument differs from the type of the dummy argument.   [W
ORKR]
        CALL DGGEV("N", "V", N, A, N, B, N, ALPHAR, ALPHAI, BETAR, VCL, N, VCR, N, WORKR, LWORK, INFO)  !Not w
ork when change to "V" to get right generalized eigenvectors
-----------------------------------------------------------------------------------^
compilation aborted for xdggev.f90 (code 1)
[/bash]

[GoldenRetriever]

That's exactly the type of error message I mentioned to.

Thanks for the tips. That's cool..

[GoldenRetriever]

Hi mecej4,

When I triedthe F95 call for GGEV as you suggested, it worked fine on the computer with Windows 7 32 bits. However when I run the same source on the other computer which run Windows 7 64bits, it comes with error:

Error 2 error #6285: There is no matching specific subroutine for this generic subroutine call. [GGEV]

All the project properties for the paths of Include and Library changed accordingly to suit with 64bit system, as well as used Link Avisor.. but I could not get any success.

Please advise if you have any hints on this.