program crashes when using an IMSL subroutine

[sbenati]

Hi,

I have experienced the following "bug".
I use CVF 6.6 with the IMSL library. I usually work on ME operating system and everything is good. Unfortunately, I have to install myprog.exe on machines that run on Win 2000 operating system and I had some troubles with the IMSL subroutine DQPROG. Apparently DQPROG is trying to use some memory that is allocated to the operating system.

That is: I Compile and Link myprog.exe in CVF and Windows 2000, then I execute it and I get the following message (that I translate from Italian):

"The instruction "0x004b609" refers to memory "0x0045b2e0": memory cannot be written"

Then I have the options of starting the Debug and a new message appears:

"Unhanded exception in myprog.exe 0x0000005 Access Violation".

and the debugger is pointing the line containing

Call DQPROG(..)

The same code works well on ME/98 machines.
I am a bit pessimistic about fixing this problem, and I know that is a question that I should address to Visual Numeric, anyway, if some of you may suggest anything, I will be grateful!

All the best, Stefano

[Steven_L_Intel1]

Are you passing constants as any of the arguments to the IMSL routine? Check to be sure that the IMSL routine isn't defined as modifying that argument. Windows ME wouldn't catch this but Windows 2000 will.

Steve

[Jugoslav_Dujic]

I don't have a reference for DQPROG at hand. Could you share some code?

The most probable reason is that you passed a constant as a real argument that is intent(inout). Judging on the addresses, I'm almost certain that is the case. You'll get that, for example, in:

call foo(1)
...
subroutine foo(i)
i = i+1
end subroutine foo

This is illegal and protection is by default on (it can cause very nasty bugs if goes unnoticed). Win9x cannot protect constants from overwriting, but NT+ can. It's by default on (Project/Settings/Fortran/Fortran data/Data Options/Constant actual arguments are read-only). (If that's the cause, fix the code, don't remove the option).

Jugoslav

[Steven_L_Intel1]

CALL QPROG (NVAR, NCON, NEQ, A, LDA, B, G, H, LDH, DIAG,
SOL, NACT, IACT, ALAMDA)

Arguments
NVAR ? The number of variables. (Input)
NCON ? The number of linear constraints. (Input)
NEQ ? The number of linear equality constraints. (Input)
A ? NCON by NVAR matrix. (Input)
The matrix contains the equality contraints in the first NEQ rows followed by the inequality constraints.
LDA ? Leading dimension of A exactly as specified in the dimension statement
of the calling program. (Input)
B ? Vector of length NCON containing right-hand sides of the linear constraints.(Input)
G ? Vector of length NVAR containing the coefficients of the linear term of the
objective function. (Input)
H ? NVAR by NVAR matrix containing the Hessian matrix of the objective function. (Input)
H should be symmetric positive definite; if H is not positive definite, the algorithm
attempts to solve the QP problem with H replaced by a H + DIAG * I such that H +
DIAG * I is positive definite. See Comment 3.
LDH ? Leading dimension of H exactly as specified in the dimension statement
of the calling program. (Input)
DIAG ? Scalar equal to the multiple of the identity matrix added to H to give a positive definite matrix. (Output)
SOL ? Vector of length NVAR containing solution. (Output)
NACT ? Final number of active constraints. (Output)
IACT ? Vector of length NVAR containing the indices of the final active
constraints in the first NACT positions. (Output)
ALAMDA ? Vector of length NVAR containing the Lagrange multiplier estimates
of the final active constraints in the first NACT positions. (Output)

[sbenati]

Men! You are great! variable "diag" is an output, not an input! What a silly mistake!

Now in my machine everything is OK! I will try to export the code elsewhere but I think that the problem is fixed!

If I were rich, I'd make you a statue!

Thanks again, Stefano

[Jugoslav_Dujic]

A part of the blame lies in IMSL.mod file (whoever wrote it). If there were INTENT(IN/INOUT/OUT) specifiers for IMSL routine arguments, you would get a compile-time error about usage and you wouldn't have spent few days searching for the cause of the bug. I guess it should be addressed to Visual Numerics?

Jugoslav

[sbenati]

Yes: it is a good idea! I will write the experience to Visual Numeric. Thanks again, Stefano

[gfthomas8]

But QPROG is part of Math/Library and not the Fortran 90 MP Library, ie, it's FORTRAN77 so there is no INTENT. The IMSL sample usage is consistent with DIAG being an output and so must not be preinitialized, merely correctly typed.

In years of using IMSL I've yet to find fault with their docummentation. I might have issues with some algorithms but this is purely subjective and I free to find alternatives.

Ciao,
Gerry T.

[Steven_L_Intel1]

There is an interface block for it in NUMERICAL_LIBRARIES. The IMSL interface blocks don't typically include INTENT attributes.

I agree that the IMSL documentation is good, but their interface blocks need a lot of help. This is one of the things I hope to impress on VNI for their release for Intel Fortran.

Steve

[gfthomas8]

I don't disagree but for anyone familiar with IMSL from FORTRAN77, the NUMERICAL_LIBRARIES module isn't required although VNI do recommend its use. As I mentioned, their useage section on a given procedure is worth following but of course YMMV.

Ciao,
Gerry T.

[Steven_L_Intel1]

I prefer to use the module as it at least gives you type checking, and also eliminates the need to manually specify the IMSL libraries as an additional dependency.

Steve