forums.silverfrost.com

cluosh · Joined: 15 Mar 2013 Posts: 20

Good evening,

I noticed a problem occuring when executing a function from a C++ DLL. Using the function from the DLL works perfectly with FTN95. The function loads a 3D model from a STL-File and does several modification to this model, which means a lot of memory is needed when the 3D models get larger.

When the stack size of the Fortran program is exceeded, the program throws an exception and stops executing. When I set the stack size higher, it can compute bigger 3D models, but this is not an option for the final program.

My question is: Is there any way to call a C++ Function without getting all variables saved into the stack, or is there a possibility to make the stack bigger dynamically?

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Its not clear what you mean here.

You can save stack space in your Fortran program by adding the
SAVE declaration to each of your programs and subroutines. This cause local variables to be put in static memory.

Like this:

PaulLaidler · Posted: Sat Mar 16, 2013 10:00 am Post subject:

How do you set the stack size higher (a SLINK command?) and why is this not an option for release?

cluosh · Joined: 15 Mar 2013 Posts: 20

I'm not sure how to describe what I mean, lets just say the function I import from a DLL uses the whole stack memory. I set the stack memory higher with "STACK 104857600" for 100 MB, which is still too small. If I set it any higher the program won't execute because of lacking RAM(according to the program). It's not an option for release, cause all the RAM would be reserved when starting the program, means if there is not enough RAM left according to the program, it won't execute.

A 3D model file with 1 MB needs more than 100 MB stack size during processing and if the stack is too small the program stops executing, but if I call the same DLL function from a C++ program it works fine.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

My recommendation is that you should consider a programming alternative that does not use 100mb of stack. The use of the stack for such large amounts is always going to cause problems.
You could move temporary local variables from the stack by using ALLOCATE. This should be a more robust approach.
If the variables are not temporary or local, why are they on the stack ?

John

cluosh · Joined: 15 Mar 2013 Posts: 20

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

Do you know what is going onto the stack ?
I would have assumed they were temproary variables being created in the routine being called.
Another possibility is they could also be array sections being genetated by the calling routine.

You need to identify what is being put onto the stack and consider an alternative.

John

jalih · Joined: 30 Jul 2012 Posts: 196

cluosh · Joined: 15 Mar 2013 Posts: 20

The DLL uses C++(new) instead of C(malloc) methods for reserving memory. Obviously variable memory reserved with "new" ends up on the stack when calling the function through Fortran.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

I'm not sure of your knowledge in this area, when you say "obviously". Is that definately the case or are you saying in must be ?

I would recommend that you identify what is the source of the 100mb.
C-Malloc and fortran-ALLOCATE do not use the stack, so if you can control this use you may be able to avoid the problem. I can confirm how to achieve this in Fortran, but I am not familiar with controlling this in C.

Is there any recursion involved ?

It should be a problem that can be solved.

John

cluosh · Joined: 15 Mar 2013 Posts: 20

Yes I mean "must be". I can't prove the C++ memory allocation is done on the stack, but if malloc works this must be the case. I can't tell if there is any recursion involved for sure, but there probably is. I'm wondering tho if there is another way to solve the problem without having to use malloc, cause the whole library is huge and using C++ memory allocation, and it be quite an effort to rewrite everything to malloc.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2615 Location: Sydney

My understanding is that malloc derived arrays is not the problem, as these do not use the stack. I say this as in Fortran, ALLOCATE does not use the stack and I understand ALLOCATE is based on malloc.

Do you have access to the Fortran or C++ code to be able to modify either ?
Have you been able to identify where the 100 mb is coming from? You have not yet indicated you have identified the source of this 100 mb.
If you have, I'd be trying to specifically shift some of these arrays from the stack. Your options in Fortran are:
Transfer the local array definitions to allocatable and allocate these arrays. ( large local arrays are the main source of stack usage)
Alternatively if these arrays are being supplied, can you control their allocation elsewhere, such as using ALLOCATE or declaring them to be in COMMON or a MODULE; or using malloc if in C++.

Rather than try to fix the whole library, is there a single routine call that is generating this specific problem? If so can you change the program performance at this location.

I don't think I can help much more unless there is more information available.

John

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

cluosh · Joined: 15 Mar 2013 Posts: 20

PaulLaidler · Posted: Tue Mar 19, 2013 5:50 pm Post subject:

What does DLL_HEADER expand to?