Access Violation

[fobermaier]

Hello everyone,
I'm working on a DLL that exports the following function:

integer(4) function LaA_AggregationGet( pLaA, iRegion )
!DEC$ ATTRIBUTES DLLEXPORT, ALIAS:'LaA_AggregationGet'::LaA_AggregationGet
!DEC$ ATTRIBUTES VALUE :: iRegion
type (T_LAA), pointer  :: pLaA
integer(4), intent(in) :: iRegion

...

end function

Accessing the function from the main program works fine, but if I try to access it from within the DLL I keep getting access-violations. I can't see that anything that is wrong, other functions are declared the same way - pointers to UDTs passed by reference and integer or real variables get the Attribute VALUE - and they can be called both form the main program and from within the DLL.

I'm using IVF9.0

Thanks in advance
Felix Obermaier

[Jugoslav_Dujic]

POINTER in the argument list rings the bell.

If the modules (.dll, exe) are linked against different versions of run-time library and the allocation and deallocation of pLaA are performed in different places, you'll get the access violation -- the modules don't share heaps and memory managers.

So, either ensure that both dlls are linked against the identical, DLL version of run-time library (debug/release and single/multithreaded must match), or ensure that the allocation and deallocation of pLaA are performed in the same module (either caller or callee).

[fobermaier]

Thanks for your reply,
but all allocation and deallocation of pLaA and its members is done within the DLL. The DLL is not linked against any Fortran runtime libraries,
The calling program is written in VB.NET.
If I remove the DLLEXPORT directive, the function works fine when called within the DLL.
The described function lies in an different module ... end module section as most exported procedures.


Thanks in advance
Felix Obermaier

[Jugoslav_Dujic]

I misread the original question -- I assumed it fails when called from another DLL.

The DLLEXPORT directive is not supposed to affect anything in the dll itself, and I find the behavior you describe quite odd. Where exactly is the access violation generated?

[Lorri_M_Intel]

It could be related to the VALUE attribute on the second argument.

Make sure that all callers of this routine have an interface (within their scope!) to declare LaA_AggregationGet

- Lorri

[fobermaier]

The access violation occurs when jumping in the LaA_AggregationGet function, the debugger won't get to the first line of code in that function.

The function is made accessible to the caller with a USE statement. Is that not enough?

Thanks
Felix Obermaier

[Jugoslav_Dujic]

Yes, that's enough.

At this point, I suggest you take this over to the Premier support. On the surface, it seems that you did nothing wrong and that it might be a compiler bug.

In the meantime, you can try (as a fairly desperate measure) to debug the code in disassembly mode (simply put a breakpoint at the calling statement, switch to disassembly and step in) -- that requires at least some basic knowledge of the assembly code though, and might not be insightful even then.

As a workaround (since your post hints that DLLEXPORT is the culprit), you may try dllexporting the routines through a DEF file (there's a similar explanation in compiler documentation) rather than DLLEXPORT statement. Even if it solves the problem, I urge you to submit the code to Premier support for investigation.

[fobermaier]

Exporting the routines with a DEF file did solve the problem, thanks for the tip.
Felix Obermaier