Internal write chrashes the DLL

[oliverk]

I am programming with VB.NET (VS .NET 2003). My VB-application makes calls to many external FORTRAN-routines. I collected these FORTRAN-routines in two DLL's, the simulation- and graphic-module.

The graphic module does some drawings using the DC of a picturebox control. I use an internal write to put some numbers on the axis and the graphs. It looks like:

WRITE(strText,'(F7.2)') xmax

Everything worked fine using CVF 6 + VB 6 and also using VB 6.0 and IF7/8. Now I am using IF 9 and VB.NET. My VB.NET application crashes right during the internal write with

System.NullReferenceException: Object reference not set to an instance of an object

Does anybody have a hint for me.

Many thanx in advance

Oliver

Message Edited by OliverK on 03-02-2006 05:55 AM

[Steven_L_Intel1]

It could be that the string is not being passed properly from VB to Fortran. Intel Fortran and CVF have different defaults as to where character lengths are passed, but if you converted the project from CVF, you should have /iface:mixed_str_len_arg to override that.

I suggest stepping into the function ith the debugger and verify that all the arguments are correct.

[oliverk]

I gave too less information, sorry about that

strText ist declared in the FORTRAN-Module as

CHARACTER*25 strText

and I also checked that xmax is always suitable with the format specifier (i.e '(F7.2)')

Meanwhile it seems to be an installation problem of VS.NET 2003 on my computer. Because the next point is, if I try to debug the fortran dll's on my computer, I always get a message about "Unmanaged Debugging Not Available".

Using an other computer everything is working fine, also the debugging of the dll's.

Thank you very much for your help, I am going to kill my computer right now :-)

Oliver

[Jugoslav_Dujic]

Isn't there a switch "Allow unmanaged debug" somewhere on VB project properties? It's possible that it's not a part of .vfproj file, but should be set up for every individual project (i.e. you can't carry it to another computer).

Is strText a local variable or a dummy-argument? If the latter, fixed-width declaration CHARACTER*25 smells like trouble...

[oliverk]

Hurra, my partner got the problem on his computer now too. So the problem seems to be alive. He guesses it could be the .NET-garbage collector. We will work on it. If we find a solution, I am going to post it here.

To Jugoslav: I did set the switch "Allow unmanaged debug" in the VB-project.

strText is a local variable inside the dll

I do not pass any text strings from VB.NET to the Fortran-DLL's. I have read all the mesages about passing arguments from VB --> Fortran and vice versa in that forum. It is a really good source.

I also checked my passed arguments inside the dll's using the debugger, therefore I am quite sure, that there is no mistake in passing arguments.

[Ray_R_1]

Hi, I have been trying to port some qwin subroutines from CVF 6.6c (where they work fine) to Intel V9.0 and have seen the same problem with the formatted internal write. I found that if I use a listdirect i.e. write(text,*)x instead of write(text,'(G11.4)')x it works, although I really want the text string to be formmatted. Please email me if you find a work around. In the mean time I going to write my own conversion routines.

RobertsRW@npt.nuwc.navy.mil

Thank you.

Ray

[Steven_L_Intel1]

Please send a test case to Intel Premier Support. If there's a bug to be fixed, we want to fix it.

[Ray_R_1]

Hello, Steve.

I have been trying to reproduce this errror in a code fragment without any success. The code that I'm having trouble with is about 4000 lines long and is very convoluted, many recursive calls and a lots of pointers. I have also tried to use a formatted write statement to a scratch file and got the same error on the write but if I use list direct I don't get the error writing to the file. Give me a couple of more days to see if I can reproduce it in a code fragment, if not I will send the subroutines with a driver program.

Ray

[oliverk]

... we still working on it:

We have 5 different computers:

1: Celeron D 2.8 GHz: no problems

2: Pentium 4 2.4 GHz: no problems

3: PIII 1.3 GHz: System.NullReferenceException

4: AMD XP 2400+: no problems

5: AMD XP 2500+: System.NullReferenceException

(a week ago I had the problem on #2)

-------------------------------------------------------------------

If I substitute

WRITE(strText, '(F7.2)') xmax

with (xmax is in this case xmax = 234.45)

WRITE(strText,*) 234.45

the called graphic routine works 6 times fine and crashes within the 7th-call at the internal write statement with the described System.NullReferenceException: Object reference not set to an instance of an object

If I start the program again it chrashed within the 6th call.

and once again: within the 7th call and now it occurs stable at the 7th call

What could it be? Does anybody have an idea?

Oliver

Message Edited by OliverK on 03-07-2006 07:20 AM

Message Edited by OliverK on 03-07-2006 08:47 AM

[Steven_L_Intel1]

My guess is that you're corrupting the stack due to a mismatch between the caller and callee. Show the VB declaration of the routine and the corresponding Fortran declaration including any directives and argument declarations.

[oliverk]

Hello Steve,

many thanks for your fast reply. Here we go

VB.NET:

Declare Function SiWaProGM_DrawIsoline Lib "SiWaProGM.dll" ( _

ByRef hWnd As Integer, _

ByRef IntegerVariables As typIntegerVariables, _

ByRef KX As Integer, ByRef x As Double, _

ByRef y As Double, ByRef z As Double, _

ByRef Normalized As Double, ByRef minNorm As Double, _

ByRef maxNorm As Double, ByRef xObs As Double, _

ByRef zObs As Double, ByRef yObs As Double, _

ByRef IsolineControl As typIsolineControl) As Integer

and the call

SiWaProGM_DrawIsoline(hOnlineFlowGrafikWnd, _

IntegerVariables, KX(0, 0), x(0), y(0), _

hNew(0), Saturation(0), minSat, maxSat, _

xObs(0), zObs(0), yObs(0), FlowIsolineControl)

in the Fortran DLL:

INTEGER FUNCTION SiWaProGM_DrawIsoline(hGrafikWnd, IntVars, KX, x, y, z, &

Normalized, minNorm, maxNorm, &

xObs, yObs, zObs, IsolineControl)

!DEC$ ATTRIBUTES DLLEXPORT :: SiWaProGM_DrawIsoline

!DEC$ ATTRIBUTES STDCALL :: SiWaProGM_DrawIsoline

!DEC$ ATTRIBUTES ALIAS : 'SiWaProGM_DrawIsoline':: SiWaProGM_DrawIsoline

!

!DEC$ ATTRIBUTES REFERENCE :: hGrafikWnd

!DEC$ ATTRIBUTES REFERENCE :: IntVars

!DEC$ ATTRIBUTES REFERENCE :: KX

!DEC$ ATTRIBUTES REFERENCE :: Normalized, minNorm, maxNorm

!DEC$ ATTRIBUTES REFERENCE :: x, y, z

!DEC$ ATTRIBUTES REFERENCE :: xObs, yObs, zObs

!DEC$ ATTRIBUTES REFERENCE :: IsolineControl

!

USE GlobalConst

USE GlobalData

TYPE (typGrafikFenster), POINTER :: Grafik

INCLUDE '..simulationsmodulparam.inc'

TYPE (typIntegerVariables) :: IntVars

INTEGER, INTENT(IN) :: hGrafikWnd

INTEGER, INTENT(IN) :: KX(IntVars%NumEl,4)

DOUBLE PRECISION:: x(IntVars%NumNP), y(IntVars%NumNP), z(IntVars%NumNP)

DOUBLE PRECISION:: Normalized(IntVars%NumNP), minNorm, maxNorm

DOUBLE PRECISION:: xObs(IntVars%NumPoints), yObs(IntVars%NumPoints), &

zObs(IntVars%NumObs)

TYPE (typIsolineControl) IsolineControl

-----------------------------------------------------------------------------------

All these arrays do not have a fixed size. I use the ReDim statement within the VB main program for allocating the array size.

I also checked the numbers in my arguments for any mismatches, but I didn't find any :-(

[Steven_L_Intel1]

Ok - that all looks fine to me. What is your setting for "Use run-time libraries" for the DLL project? I recommend "multithreaded DLL" (not any of the Debug variants).

[oliverk]

Right now, I have "Debug Single-threaded DLL". I gonna try the Multithread DLL ....

Oliver

[oliverk]

... still the same, after the 7th call the System.NullReferenceException occurs

I also think, that the problem is caused by a corrupted stack. The corruption occurs somewhere else in the DLL and will turn out later during the internal write to the NullReferenceException. The question is: How find the bug in the code?

I am really happy, that I am able right now to reproduce the error. So I can search for it. But on this machine (#3) the debugger is not yet available (unmanaged debugging not available).

I keep searching ....

Oliver

[Steven_L_Intel1]

There's a VB.NET project option to enable unmanaged code debugging.

[oliverk]

Debugging does not work on comupter #3 and I don't know why. I already reinstalled IF9, VS.NET 2003. But every time if I check the box "enable unmanaged debugging" (This is a translation from german --> english, I hope it meets that, what you see in the properties box of an VB.NET-project) and try to start the debugging, I get an error message "Unmanaged debugging not available".

Debugging the FORTRAN-DLL works on #2, but it don't have the problem there anymore ....

Oliver

[Steven_L_Intel1]

Interesting. I would suggest:

1. Uninstall Intel Fortran integration into VS.NET
2. Do a Repair/Reinstall of VS.NET (Add/Remove Programs, Change/Modify)
3. Reinstall Intel Fortran integration

See what happens

[oliverk]

Hello Steve,

1.)I uninstalled the Intel Fortran integration into VS.NET
2.) I did a Repair/Reinstall of VS.NET (Add/Remove Programs, Change/Modify)
3.) I reinstalled theIntel Fortran integration

-------------------

and here are my results:

1.) debugging works fine (I should have known this, thank you)

2.) the System.NullReferenceException occurs now in my other DLL also within an internal write like

CHARACTER*255 Zeile

WRITE(Zeile, 1020)

1020 FORMAT('Der aktuelle Zeitschritt..')

---------------------------------

Meanwhile I also found the older threads on the similar topic #8647 form 04-08-2004 and I am going to try, to link again against the multithread dll.

[Steven_L_Intel1]

Please also make sure that you are using a current compiler (9.0.030).

[oliverk]

I downloaded .030 at 03-06-2006 and installed it also that day immediately after downloading.

Now I tried to link against the multithread dll (I also set the option "Use Common Windows Libraries" = NO) and got the System.NullReferenceException at its usual, formerly known place in the graphic-dll. But it occurred now not before the 286th call to the routine.

Another point: On this machine (#3, W2K) I do not need to have the libraries libifcoremd and libmmd in the same directory like the exe (..in). On the othercomputer (#2, WinXP) I need to have themin the..in-directory. Could it mean anything else than a missing variablein the path environment?

[Steven_L_Intel1]

The need for the DLL in the local folder is simply a PATH issue.

Here's what I would do. I would set a breakpoint in the debugger at the Fortran routine. When the breakpoint is reached, I would note the value of the ESP register (you'll need to view the Debug..Registers window.) Then let execution continue until the breakpoint is reached again. Ideally, the ESP value should be the same each time the Fortran routine is called, assuming it is from the same location in the VB code. If it is not, that suggests a calling interface error with adjusting the stack.