Dll problem

Dll problem

I have a problem with lapack95 with fortran.
I want to develop a dll for another application which written with vc++,the dll was developed with visual fortran and linked the lapack 95,when i call geevx to compute the eig of a complex matrix,The application crupt with a tip:access violation 0xc0000000005,the call format is geevx(a,b,c,d), I known the lapack is static lib,but how to solve the problem?

12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Beijihuohu,

Just guess, the problem may be the calling conversion between fortran and C. for example, the call format in C++ may be geevx(&a,&b,&c,&d).

Could you please provide a test project to reproduce the problem so we can
diagnose the problem?

Regards,
Ying

Thank you! Ying H,the example is simple as two part:
The host is:

typedef int (*MYPROC)(int &n, double bR[3][3],double bM[3][3],double cR[3],double cM[3],double dR[3][3],double dM[3][3]);

void CTestFortranDllDlg::OnBnClickedButton1()

{

// TODO: Add your control notification handler code here

//int a=5,b=16;

HINSTANCE hIns;

hIns = LoadLibraryEx(_T("F:\\practise\\DFLL\\DFLL\\Debug\\DFLL.dll"),NULL,DONT_RESOLVE_DLL_REFERENCES);

MYPROC fun= (MYPROC)GetProcAddress(hIns,"DFLL");

double br[3][3],bm[3][3];

double cr[3],cm[3];

double dr[3][3],dm[3][3];

for(unsigned long i=0;i<3;i++)

{

for(unsigned long j=0;j<3;j++)

{

br[i][j]=i+1;

bm[i][j]=j+4;

}

}

int n = 3;

fun(n,br,bm,cr,cm,dr,dm);

::FreeLibrary(hIns);

}

The Client is:

subroutine DFLL(n,br,bm,cr,cm,dr,dm)

USE mkl95_PRECISION, ONLY: WP =>DP

USE mkl95_LAPACK, ONLY: GEEVX

implicit none

! Expose subroutine DFLL to users of this DLL

!

! Variables

! Body of DFLL

! The following directive exports the routine and sets the global name

!DEC$ ATTRIBUTES DLLEXPORT::DFLL

INTEGER n,i,j,D

INTEGER(4) ILO, IHI

REAL(8) br(3,3)

REAL(8) bm(3,3)

REAL(8) cr(3)

REAL(8) cm(3)

REAL(8) dr(3,3)

REAL(8) dm(3,3)

complex(WP) :: ABNRM

COMPLEX(WP)::BZ(3,3)

COMPLEX(WP)::CZ(3)

COMPLEX(WP)::DZ(3,3)

COMPLEX(WP)::EZ(3,3)

complex(WP)::RCONDE(3), RCONDV(3),SS(3)

!do i=1,3

! do j=1,3

! BZ(i,j)=cmplx(br(i,j),bm(i,j))

! end do

!end do

do i=1,3

do j=1,3

BZ(i,j)=cmplx(I,J+3)

end do

end do

CALL GEEVX(BZ,CZ,DZ,EZ,'V',ILO, IHI)

DO i=1,3

DO j=1,3

Dr(I,J)=REAL(EZ(I,J))

Dm(I,J)=IMAG(EZ(I,J))

END DO

END DO

DO I=1,3

Cr(I)=REAL(CZ(I))

Cm(I)=IMAG(CZ(I))

END DO

end subroutine DFLL

when i debug the dll,I find it will be cruped when i call geevx procedure. I don't kown why.
This is my first chance to uses dllmadewith fortran, Then i have to use lapacke interface for c++,
It's fluently, there is no problem to make the dll.
I doubt that the problem just be triggered by an option with compiling.
Than you for your help!

Hi,

The problem may be caused by wrong value of the fifth parameter. Indeed, the F95 interface you are using is as follows

call geevx(a, w [,vl] [,vr] [,balanc] [,ilo] [,ihi] [,scale] [,abnrm] [,rconde] [, rcondv] [,info])
where

balanc

CHARACTER*1. Must be 'N', 'P', 'S', or 'B'. Indicates how the input matrix should be diagonally scaled and/or permuted to improve the conditioning of its eigenvalues.

If balanc = 'N', do not diagonally scale or permute;

If balanc = 'P', perform permutations to make the matrix more nearly upper triangular. Do not diagonally scale;

If balanc = 'S', diagonally scale the matrix, i.e. replace A by D*A*inv(D), where D is a diagonal matrix chosen to make the rows and columns of A more equal in norm. Do not permute;

If balanc = 'B', both diagonally scale and permute A.

Computed reciprocal condition numbers will be for the matrix after balancing and/or permuting. Permuting does not change condition numbers (in exact arithmetic), but balancing does.

In other words, this parameter can take values 'N','P','S','B' but not 'V'.
Probably you misinterpreted it with JOBV[L/R] parameters which are not needed in F95 - presence of respective argument VL or VR actually means that the parameter is 'V'.

Thanks,
Victor

Victor:
Thank you for your help!
I tried again with the parameter 'P' .'N' .'S' and'B',but failed, I don't understand why the lapacke interface is right with the same parameters. I read the mkl document again,but steer can't find the problem,Can you give me the code fragment calling the geevx in the dll? I have tried it in execution files(.exe) ,It works perfect.But if you use it in dll ,the host will be crashed.

Hi,

Could you please share with us way how you created your dll and what MKL libraries were used?

Thanks,
-- Victor

Victor
Than you for your help. The attachment is dll project using intel composer 2011 fortran version.The option could be reviewed with project fils.
Than you again!

Attachments: 

AttachmentSize
Downloadapplication/rar DFLL.rar47.32 KB

Hi beijihuohu,

Thanks for the test case. We can reproduce the problem. It seems there is problem with the dll call. We are looking into it and keep you update if any ideas.

Thanks
Ying

 Ying:

     Thank you!The expection for you!

Hi Beijihuohu,

All Thankes do to our developersas they actually rootcaused the issue and the resolution is the following:

1) Instead of

hIns = LoadLibraryEx(_T("..\\DFLL\\debug\\DFLL.dll"),NULL,DONT_RESOLVE_DLL_REFERENCES);

in source file TestLapack.cpp please use
hIns = LoadLibrary(_T("..\\DFLL\\debug\\DFLL.dll"));

with the correct indication of the way to the library;

this correction is the direct sequence of the description

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179(v=vs.85).aspx

where the item about DONT_RESOLVE_DLL_REFERENCES has NoteDo not use this value;

DONT_RESOLVE_DLL_REFERENCES0x00000001

If this value is used, and the executable module is a DLL, the system does not call DllMain for process and thread initialization and termination. Also, the system does not load additional executable modules that are referenced by the specified module.

NoteDo not use this value; it is provided only for backward compatibility. If you are planning to access only data or resources in the DLL, use LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE or LOAD_LIBRARY_AS_IMAGE_RESOURCE or both. Otherwise, load the library as a DLL or executable module using the LoadLibrary function.

2) Optional, if yourproject can't founddependency libraries.

In TestLapack Project Properties -> Debugging -> Environmentyou may need make sure PATH=c:\program files (x86)\INTEL\COMPOSERXE-2011\REDIST\ia32\compiler (the path to where libifcoremdd.dll is) because DFLL.dll is dependent on libifcoremdd.dll as dumpbin /DEPENDENTS command on DFLL.lib tells.

After these two corrections, TestLapack project runs well.

Please try these corrections at your side and let us know the results to be happy :)

I attached the fix project.

Sincerely,

Ying

Attachments: 

AttachmentSize
Downloadapplication/zip DFLL_fix.zip98.63 KB

Thank you
I tried it and find it works as i expected,But could i understand as follow:
The lapack is a static libaray.If the lapack never depends on other libaray,The calling previous will be successfull,But the lapack depends on the libaray i don't known,so the problem prompted.
Thank you once more!

Hello beijihuohou,

The problem should be thefunction LoadLibraryEx and the parameter DNT_RESOLVE_DLL_REFERENCES .They arenot suitable to beused for call a dll which ask dllmain toinitialize and temenate, also need to access all data and resouce and code in the dll.As theDFLL.dllbased on MKL static library, the DFELL.dll won't depend on any other mkllibrary. (you can check the dll dependency by MSVCtools depends.exe) So the problem is not becausethe lapack library'sdependency.

Best Regards,
Ying

Leave a Comment

Please sign in to add a comment. Not a member? Join today